How can update the fields?

Hi all,

I am curious to know if there is a method to grant specific users the ability to update fields like first name, last name, department, Employee ID, and salary. In the event of a salary increase for specific employees, the changes would be reflected in an Excel sheet, which can then be updated from FileMaker or any relevant fields.

Referencing the screenshot below for context.

Hello, @Saeed. Normally, we control such things with Privilege sets defined in File... Manage... Security.

If you assign a user to a privilege set, for example "Management", you can allow those assigned users to edit certain fields while not allowing users in a different privilege set, such as "Client Services". You also can control visibility of data as well as access to layouts, etc. there.

Further, if you want only "Alice" who is assigned to the "Management" set to be allowed to edit, but "Ted" who is also assigned to the "Management" set is not allowed, we can handle that with script triggers on the individual fields or the the script which presents the layout for edits, etc.

Does any of that make sense?

1 Like

Thank you for your response.

The reason I posed this question is that the HR department has requested me to update certain personal details in relation to salary fields as you know this is not will be first request will be again and agin in future. I am seeking a method to provide them with the capability to edit the Excel sheet and subsequently update it in FileMaker by pressing a button.

I hope the clarification is clear now; sometimes my concern may not have been conveyed accurately initially.

Any recommendations you may have will be appreciated, as every time.

Thank you for clarifying, @Saeed. I suggest that you have a few tasks before you. First, if you have not already, look in to the security provided by Privilege sets, so that you have sets based on departments and positions within each. For example, in most of my solutions the Finance department has almost "read-only" privileges with the exemption of a few fields like financeNotes, auditBy, etc. HR can add staff, define roles, credentials, emergency contact info, etc. but only have access to HR related layouts and data. And Staff can see their own HR record only, and so on.

Once you have that part of your solution well defined, I would look into scripted imports for the data you describe (in an excel file). Insist that the Excel layout be absolutely consistent as a template.

I suggest creating a new table into which the excel data is imported so that the data can be confirmed and possibly edited. (This step is optional, but my typical preference.).

Finally, on the "utility import layout" for the new table mentioned above, allow the appropriate user to call a script (by button) to update the appropriate records. Since this is an update process, you'll want to include a match field in your Excel data, typically an ID such employeeID in this case.

To expand this example a bit: I have such a utility in an inventory management system (same type of requirement) where an excel template is used by staff to enter the appropriate data. This is first done outside of FM (in Excel) only because they are bringing together materials from across the inventory and manipulating the data a bit. THEN the user opens the import utility layout, clicks a button to import the new data into the Utility Intermediate table; they are asked to confirm deleting the previously imported records; then asked to select the Excel file to import.

Upon the import, various rows are deleted (due to the template having some Sum totals and such, and a title row) and delete any blank records/rows that were in the Excel file. There are some additional scripts on the layout to run, and some scripted validation, etc. Once they're happy with the import, a button allows them to process it into inventory, updating what's needed or creating new records, etc.

I know this is long-winded, but I'm hoping to help you envision a process so that the requirements seem more obvious and accessible. When this type of process is new to someone, I often suggest to simply do each step manually, drawing from the menus and writing each step down as you complete it. This then will translate into much of your script(s).

I apricate what you wrote because give me the deep the details my issue. totally i agree with you if this case is first time will be difficulty.

my begin to start to create script as shown below Unfortunately i getting the message is 409 import order is invalid.

It looks like you have a match field (first one) which is also set to auto-enter (the orange gear sprocket at right). That will cause an import error.

1 Like

@Saeed There are a number of ways to accomplish these restrictions, with varying degrees of Pros/Cons/difficulty/flexibility

  • The most robust (and most obscure): in the privilege set, on record and layout security, you can restrict any given privilege set from seeing, editing, deleting, etc. any field, or access to any layout. (restricting layout access in this way, has potential issues in that IF a user gets a GTL to that layout with no access, the grey screen with << no access >> on it, does not provide an exit. Care must be taken in coding to not paint ones-self into that corner). If you restrict access to field(s), then they show as << no access >>. Tip; HIDE on field content of "?" with remove those from the layout visibility.
  • A separate and near duplciate layout, with conditional branches in the GTL code based on privilege set. Fields have be non-browsable or even removed
  • Field level HIDE conditions, based on privilege set.
1 Like