Richard Carlton, Mar 4, 2024, FileMaker Training Videos
Menu:
- Introduction
- Overview of Security in FileMaker
- Understanding Record-Level Access Control
- Creating Custom Privileges for Record Access
- Implementing Conditional Record-Level Access
- Field-Level Access Control
- Managing Layout-Level Access
- Custom Layout Privileges and Workflow Control
- Using Script Triggers for Workflow Enforcement
- Combining Record and Layout-Level Access for Robust Security
- Managing Extended Privileges and User Roles
- Best Practices for Testing Security
- Conclusion
Introduction
Ensuring the security of your FileMaker database is a critical component of maintaining data integrity and ensuring compliance with industry standards. Properly managing access to records and layouts not only protects sensitive data but also tailors the user experience based on roles and responsibilities. This guide will explore the comprehensive steps required to implement robust record and layout-level access controls in FileMaker, providing an in-depth view of the tools available to developers and administrators.
This blog post aims to break down FileMaker’s powerful security tools, highlighting best practices and giving detailed instructions on setting up conditional access, record-level privileges, and layout-level permissions. You’ll learn to control user interaction with data while improving the overall user experience.
Overview of Security in FileMaker
FileMaker provides several layers of security, from account management to granular record and layout control. The two primary components for controlling access at the database level are:
- Record-Level Security: Controls what records a user can view, modify, or delete.
- Layout-Level Security: Manages which layouts users can access or edit, and whether they can modify the data displayed on those layouts.
These layers interact with FileMaker’s Privilege Sets, which define user permissions for different parts of the solution, such as access to scripts, layouts, and value lists. Combining these features with account-level security ensures that your database is both flexible and secure.
Understanding Record-Level Access Control
What is Record-Level Access?
Record-level access determines which records users can view or modify within a table. By using privilege sets and calculated conditions, you can control who sees or interacts with specific records. For example, a user in the “Sales” department might only need to view sales records, while another user in “Finance” might require access to both sales and financial records.
Why is Record-Level Security Important?
- Data Protection: Limiting access to sensitive records ensures that users only see information relevant to their role, which helps prevent data breaches.
- Compliance: Record-level security is vital for adhering to regulatory standards such as GDPR, HIPAA, or other data privacy laws. By controlling which records are visible to different users, you reduce the risk of unauthorized access.
- User Experience: Filtering data based on user roles ensures that each user only sees what they need to see, improving focus and reducing clutter in the interface.
Key Record-Level Security Features in FileMaker:
- View, Edit, and Delete Restrictions: You can set different permissions for viewing, editing, and deleting records.
- Conditional Access: By using calculations, you can define conditions that must be met for a user to access or modify a record (e.g., access only allowed if the “flag” field equals 1).
Creating Custom Privileges for Record Access
Step-by-Step Process:
- Navigate to Security Settings:
- Open your FileMaker solution, go to File > Manage > Security, and select the user or group whose access you want to configure.
- Create or Modify Privilege Sets:
- Under Manage Privileges, select an existing Privilege Set or create a new one by duplicating a set like Data Entry Only. Name it appropriately (e.g., “Sales Access”).
- Set Custom Record Access:
- Under the Records tab, choose Custom Privileges for each table. Here, you can define whether the user can view, edit, or delete records.
- You can apply these settings globally (for all records in a table) or on a per-record basis by using the Limited option.
- Use Calculations for Fine-Tuned Control:
- Select Limited and define a calculation to restrict access to specific records. For instance:
If ( flag = 1; 1; 0 )This calculation only allows access to records where the “flag” field equals 1.
- Select Limited and define a calculation to restrict access to specific records. For instance:
- Test Your Settings:
- After configuring the privilege set, test the access restrictions by logging in as a user with the relevant role. Make sure to try multiple scenarios to ensure that records are being filtered as expected.
Implementing Conditional Record-Level Access
How Conditional Access Works
FileMaker allows you to restrict access based on calculated values. For example, you can configure access so that users can only view records assigned to them or records that meet specific criteria (e.g., status or date).
Steps for Implementing Conditional Access:
- Define Conditions: Use the Limited option within Custom Privileges and set a calculation that governs access.
- Example Calculation:
- Allow access only if the current user is assigned to a record:
Get ( AccountName ) = AssignedTo - This calculation restricts access to records where the current logged-in user matches the “AssignedTo” field.
- Allow access only if the current user is assigned to a record:
- Advanced Techniques:
- You can combine multiple conditions using
ANDorORlogic. For example, if you want users to access a record only if it’s active and assigned to them:If ( Status = "Active" and Get ( AccountName ) = AssignedTo; 1; 0 )
- You can combine multiple conditions using
Testing Conditional Access:
- User Scenarios: Simulate different user scenarios to test whether conditional access works. Log in with different accounts and ensure that records are correctly shown or hidden based on your conditions.
Field-Level Access Control
In addition to controlling which records users can access, FileMaker allows you to limit access at the field level. This is useful when certain users need to see a record but shouldn’t interact with all of its fields.
Configuring Field-Level Access:
- Navigate to Field Access Settings:
- While editing your privilege set, under Records, click on Custom Privileges and choose Field Access.
- Define Permissions for Each Field:
- For each table, you can define whether fields are visible or modifiable. For example, you can set a View Only restriction on fields like “Total Cost” but allow users to edit fields like “Customer Name.”
- Field-Specific Calculations:
- You can also create field-specific access rules. For instance, a user can edit a field only if another field (e.g., a checkbox) is unchecked.
Managing Layout-Level Access
Layout-Level Security Overview
While record-level access controls which data a user can view or edit, layout-level security controls the user interface—the layouts themselves. This can help you hide entire sections of your solution from users who don’t need access.
Step-by-Step Process:
- Modify Layout Access in Privilege Sets:
- Go to File > Manage > Security, edit the privilege set, and under Layouts, select Custom Privileges. This will display a list of all layouts in the solution.
- Restrict Layout Access:
- For each layout, choose View Only, Modifiable, or No Access. For instance, you may grant sales users Modifiable access to the “Sales Entry” layout but restrict access to financial layouts.
- Dynamic Layout Access:
- You can also use layout scripts to dynamically adjust which layouts are available to users based on their role. For example, you might have a script that redirects unauthorized users to a default layout if they attempt to access a restricted one.
Custom Layout Privileges and Workflow Control
Layout-level privileges can enhance workflow management by limiting which screens users can access at specific stages of a process.
Practical Examples:
- Sales Process:
- During the sales process, users might need access to the “Customer Details” layout but not the “Invoice” layout until certain conditions are met (e.g., an order is confirmed).
- Script triggers can automate layout navigation based on workflow steps. For example, after confirming an order, a trigger can automatically move the user to the “Invoice” layout.
- User Role Management:
- Restrict access to admin layouts by setting custom privileges for different roles (e.g., admin vs. user). You could hide advanced reporting layouts from basic users while allowing full access to administrators.
Managing Layout Availability with Scripts:
Using script triggers (such as On Layout Enter) ensures that users only access layouts when they should. A script can evaluate user roles or record conditions and direct the user to the correct layout dynamically.
Using Script Triggers for Workflow Enforcement
What Are Script Triggers?
Script triggers are event-driven actions that execute automatically when users interact with a layout or field. They are useful for enforcing workflow processes and restricting user actions based on conditions.
Types of Script Triggers:
- Pre-Triggers: Fired before an action is performed, such as when a user attempts to enter a field. You can use these to check conditions before allowing the user to proceed.
- Post-Triggers: Fired after an action is completed, such as when a record is saved. Post-triggers can validate data and ensure compliance with business rules.
Example of a Pre-Trigger for Access Control:
You can use a script trigger to prevent users from editing a record if a specific condition is met:
If [Get ( AccountName ) ≠ AssignedTo]
Show Custom Dialog [ "Access Denied" ]
Exit Script
End If
In this example, users can only edit a record if they are assigned to it. Otherwise, they are shown an “Access Denied” message, and the script prevents them from continuing.
Combining Record and Layout-Level Access for Robust Security
The true power of FileMaker’s security features is unlocked when record-level and layout-level controls are used in tandem. This combination allows for a highly flexible and secure system.
Scenario: Managing Sales and Finance Access:
- Record-Level: Sales users can view and edit sales records but cannot access financial records.
- Layout-Level: Sales users are only shown layouts related to customer and sales information, while financial users have access to financial layouts.
By combining these two security levels, you can ensure that users are limited to their functional area and cannot inadvertently access unrelated or sensitive data.
Managing Extended Privileges and User Roles
What Are Extended Privileges?
Extended privileges define how users access FileMaker solutions beyond the database itself, such as via WebDirect, ODBC/JDBC, or FileMaker Go.
Setting Up Extended Privileges:
- Navigate to Extended Privileges:
- In Manage Security, under each privilege set, you’ll find a list of extended privileges such as fmwebdirect (for web access) and fmapp (for FileMaker Go).
- Assign Extended Privileges:
- Enable or disable extended privileges based on the user’s role. For example, allow admins to access the database via WebDirect but restrict this access for general users.
- Testing Extended Access:
- After enabling extended privileges, test the solution across all platforms (e.g., FileMaker Go, WebDirect) to ensure access behaves as expected.
Best Practices for Testing Security
Security settings should always be thoroughly tested to avoid gaps that could expose sensitive data or disrupt workflows.
Recommended Testing Process:
- Use Multiple Environments:
- Set up separate test and production environments. Always test security settings in a safe environment before applying them to a live system.
- Create Test User Accounts:
- Use test accounts with different roles to simulate real-world usage and ensure that access permissions work as intended.
- Monitor Logs and Errors:
- Regularly review server logs and error messages to identify any potential security issues. Ensure that unauthorized users are not accessing restricted data.
- Test Cross-Platform Access:
- Test access from FileMaker Pro, FileMaker Go, and WebDirect to ensure that security settings are applied consistently across all platforms.
Conclusion
In FileMaker, record and layout-level access control are essential tools for managing user interaction with your database. By using these features effectively, you can protect sensitive data, streamline workflows, and ensure that users only access the information relevant to them. Combining these access controls with calculated conditions and script triggers creates a highly secure and flexible system. Remember to test your security configurations thoroughly and update them as your solution evolves to ensure ongoing protection and compliance with best practices.
This comprehensive guide provides a step-by-step process for configuring FileMaker security, ensuring that you have the tools and knowledge necessary to secure your solutions while offering a user-friendly experience.
Check List
FileMaker Record and Layout Level Access Checklist
| Category | Checklist Step | Description | Action Required | Notes/Additional Information |
|---|---|---|---|---|
| 1. Overview and Planning | Define User Roles | Identify and define the different user roles within your organization (e.g., Admin, Sales, Finance). | List out all user roles and their responsibilities to determine access needs. | Clear role definitions are crucial for effective access control. |
| Determine Access Requirements | Outline what each role needs to access within the database (records, layouts, fields). | Create a matrix mapping roles to access levels for records and layouts. | Helps in visualizing and planning access levels systematically. | |
| Document Security Policies | Establish and document your organization’s security policies related to data access and protection. | Develop a security policy document that outlines rules, guidelines, and procedures for data access. | Ensures consistency and compliance with organizational standards and regulations. | |
| 2. Setting Up Record-Level Access | Navigate to Security Settings | Access the security settings within FileMaker. | Go to File > Manage > Security in your FileMaker solution. | |
| Create Custom Privilege Sets | Develop specific privilege sets tailored to different user roles. | In Manage Security, select Manage Privileges, then New Privilege Set. | Avoid using default privilege sets; customize them to fit your security needs. | |
| Configure Record Access | Define what records each privilege set can view, edit, or delete. | Under Records tab in privilege sets, select Custom Privileges and set conditions using calculations. | Example condition: If ( Get ( AccountName ) = AssignedTo ; 1 ; 0 ) to restrict access to assigned records. | |
| Implement Conditional Logic | Use calculations to set dynamic access based on record conditions or user attributes. | Define calculations within Custom Privileges to control access dynamically. | Example: Allow editing only if Status = "Active". | |
| Assign Users to Privilege Sets | Link each user account to the appropriate privilege set. | In Manage Privileges, assign each user to their respective privilege set. | Ensure that each user is correctly mapped to prevent unauthorized access. | |
| 3. Setting Up Layout-Level Access | Define Layout Access Permissions | Control which layouts each privilege set can view or modify. | In Manage Privileges, under Layouts section, set View Only, Modifiable, or No Access for each layout. | Tailor access based on user roles to limit interface exposure. |
| Restrict Sensitive Layouts | Ensure sensitive or administrative layouts are only accessible to authorized roles. | Set No Access for layouts like “Admin Dashboard” for non-admin roles. | Prevents users from navigating to layouts that contain sensitive information or administrative functions. | |
| Hide Restricted Layouts from Navigation | Remove or hide layouts from navigation menus for users without access. | Customize navigation menus and scripts to exclude restricted layouts based on user roles. | Enhances user experience by decluttering navigation and reducing confusion. | |
| 4. Implementing Field-Level Access | Identify Sensitive Fields | Determine which fields contain sensitive or restricted information. | List out fields like “Salary”, “Personal ID”, “Financial Data” that require restricted access. | Critical for protecting specific pieces of data within records. |
| Configure Field Access Permissions | Set visibility and edit permissions for fields based on privilege sets. | In Manage Security, under Fields section, set View Only, Modifiable, or No Access for each field. | Example: Set “Salary” field to View Only for Sales role and No Access for General Users. | |
| Use Conditional Formatting | Apply conditional formatting to visually indicate field access restrictions. | Use Conditional Formatting to change field appearance based on access permissions. | Improves user awareness of editable vs. non-editable fields. | |
| 5. Utilizing Script Triggers | Identify Workflow Points | Determine where script triggers can enforce security rules (e.g., field entry, record save). | Map out workflows and identify key interaction points where triggers can be applied. | Helps in maintaining consistent security enforcement throughout the user interaction. |
| Set Up Pre-Triggers | Implement pre-triggers to check conditions before allowing actions (e.g., OnObjectEnter). | Attach scripts to pre-triggers like OnObjectEnter, OnRecordLoad to validate access before proceeding. | Example: Prevent editing if record is locked by checking a flag field. | |
| Set Up Post-Triggers | Use post-triggers to validate or modify data after actions are performed (e.g., OnRecordCommit). | Attach scripts to post-triggers like OnRecordCommit to enforce data integrity after edits. | Example: Log changes or notify administrators after a record is modified. | |
| Create Secure Scripts | Develop scripts that handle access control logic securely and efficiently. | Write scripts that check user roles and permissions before performing actions. | Ensure scripts are optimized and free from vulnerabilities that could be exploited. | |
| 6. Combining Record and Layout Security | Integrate Record and Layout Controls | Use both record and layout-level access to create a multi-layered security system. | Ensure that users have appropriate access at both record and layout levels, reinforcing each other. | For instance, a user can only view certain records on specific layouts, preventing unauthorized data exposure. |
| Implement Role-Based Layout Access | Assign layout access based on user roles to streamline workflows and enhance security. | Define which layouts are accessible to each role within Manage Privileges under Layouts section. | Example: Sales users have access to “Sales Entry” layouts but not “Financial Reports”. | |
| Use Scripts to Manage Navigation | Control user navigation through scripts that check permissions before accessing layouts. | Create navigation scripts that validate user permissions before allowing access to certain layouts. | Prevents users from bypassing layout restrictions by directly selecting layouts from menus or URLs. | |
| 7. Managing Security Privileges | Create and Assign User Accounts | Set up user accounts and assign them to appropriate privilege sets. | In Manage Security, create user accounts and link them to predefined privilege sets. | Ensure strong, unique passwords for each account to enhance security. |
| Define Extended Privileges | Configure access beyond the FileMaker application, such as WebDirect or FileMaker Go. | In Manage Privileges, enable or disable extended privileges like fmwebdirect, fmgo as needed. | Restrict extended access to necessary roles only to minimize potential attack vectors. | |
| Regularly Review and Update Privilege Sets | Periodically audit and update privilege sets to reflect any changes in roles or requirements. | Schedule regular security reviews to update privilege sets based on organizational changes or security audits. | Keeps the security model up-to-date and responsive to evolving needs. | |
| 8. Testing and Validation | Set Up Test Environments | Create separate environments for testing security settings without affecting production data. | Duplicate your solution and configure it in a staging environment for testing purposes. | Prevents accidental disruptions to live systems during testing. |
| Create Test User Accounts | Develop test accounts with different roles to simulate various access scenarios. | Set up test accounts that mimic real user roles and permissions for thorough testing. | Allows comprehensive testing of security configurations from multiple perspectives. | |
| Perform Access Tests | Test each user role to ensure access permissions are correctly enforced. | Log in with each test account and verify that access to records, layouts, and fields aligns with defined permissions. | Document any discrepancies and adjust settings accordingly. | |
| Use Automation Scripts for Testing | Develop scripts that automate the testing of access controls across different roles and scenarios. | Create scripts that can simulate user interactions and verify access permissions programmatically. | Enhances testing efficiency and consistency. | |
| Monitor and Log Security Events | Keep track of access attempts and security-related events through logging. | Enable and configure FileMaker’s logging features to capture security events and access attempts. | Helps in identifying and responding to unauthorized access attempts or breaches. | |
| 9. Maintenance and Monitoring | Schedule Regular Security Audits | Conduct periodic security audits to ensure ongoing compliance and effectiveness of access controls. | Perform comprehensive reviews of user roles, privilege sets, and access logs on a regular basis (e.g., quarterly). | Ensures that security measures remain robust and aligned with organizational policies. |
| Update Security Settings with Solution Changes | Revise security configurations whenever there are significant changes to the solution’s structure. | Adjust privilege sets and access controls when adding/removing tables, layouts, or fields. | Maintains the integrity of the security model as the solution evolves. | |
| Backup Security Configurations | Regularly back up your security settings to prevent loss in case of system failures. | Export security settings and store them securely as part of your overall backup strategy. | Facilitates quick restoration of security configurations |
