The field-level permissions feature enhances ActivityInfo's security model by allowing administrators to control access to specific fields within a form. This feature gives administrators the flexibility to design forms that multiple users with different roles will be able to work with without compromising security.
In a database that contains a “Patients” form used to manage medical records, users may collect information such as patient names, gender, date of birth, national identification numbers, phone numbers, physical addresses, diagnoses, and treatment details. While this information is necessary for providing care, not every user in the medical facility should have access to the full patient record.
Information such as patient names, phone numbers, addresses, and identification numbers can directly identify an individual. This type of information is considered Personally Identifiable Information (PII) and must be protected to safeguard patient privacy and confidentiality.
The field-level permissions allow administrators to restrict access to sensitive data so that only authorized users, such as clinicians or medical officers, can view or edit these fields. Other users may still work with the same records while sensitive information remains hidden.
If a user role does not have “view” access to a specific field, the field values remain redacted. This means the user can continue to access and work with the record, but the restricted information is not visible to them. If a user role does not have “edit” access to a specific field, the user will not be able to make any changes to the value in that field.
Setting up field-level permissions to view and edit field values
An administrator can grant permissions to view or edit field values at the user-role level. In this example, we have a “Patients” form with the following fields:
- Full Name
- Gender
- Date of Birth
- Phone Number
- Known Allergies
- Pre-existing conditions
- Clinical Notes
There are two different roles: Registration Clerk and Clinical Officer.
- A Registration Clerk may view and edit patient demographic information.
- A Clinical Officer may view demographic information and edit the clinical notes, known allergies and pre-existing conditions.
Registration clerk user role
The registration clerk is the first person to meet the patient. Their job is to collect patient details, such as their full name, gender, date of birth, phone number, and email.
As such, they are not allowed to view or edit other fields in the “Patients” table.
The following are the steps to configure this role to only view and edit the required fields.
- Go to Database settings and select Roles.
- Select the Registration clerk role which you want to set the field-level conditions.
- Click on Grant resources and select the form and click on Select resource.
- Grant basic permitted operations to the role.
- Scroll down in the permissions panel on the right side and select the Manage conditions option_._
- Select Add-Field level condition to create a condition that allows users with the Registration Clerk role to view and edit field values when the conditions set are met. Under Allow, select View and under When, select all.
This goes on to read, Allow View when all of the following apply…
- Add the rules that should apply to the statement above.
The condition will now read_… Allow View when all of the following apply: is not Known Allergies, is not Pre-existing conditions, is not Clinical Notes._
This means that any other field that is not indicated in this condition, can be viewed and edited by users with this role.
Click on Set conditions.
- Scroll down and click on Save in the roles management panel.
- The users with this role are able to edit and view all other fields except Known Allergies, Pre-existing conditions and Clinical Notes which remain redacted.
Clinical officer user role
After a patient has been registered, the next step is to visit the clinician, who is assigned Clinical Officer user role in the system.
The clinical officer needs to view patient details such as full name, date of birth, and gender, but is not permitted to edit these fields. They do, however need to edit details such as known allergies, pre-existing conditions, and clinical notes.
The following are the steps to configure this role to access only the required fields.
- Go to Database settings and select Roles.
- Select the Clinical Officer role which you want to set the field-level conditions.
- Click on Grant resources and select the form and click on Select resource.
- Grant basic permitted operations to the role.
- Scroll down in the permissions panel on the right side and select the Manage conditions option_._
- Select Add-Field level condition to create a condition that allows users with the Clinical Officer role to view and edit field values when the conditions set are met. Under Allow, select Edit and under When, select any.
This goes on to read, Allow Edit when any of the following apply…
- Add the rules that should apply to the field above.
The condition will now read_… Allow Edit when any of the following apply: is Known Allergies, is Pre-existing conditions, is Clinical Notes._
This means that any other field that is not indicated in this condition, cannot be edited by users with this role.
Click on Set conditions.
- Scroll down and click on Save in the roles management panel.
- The users with this role are able to edit the Known Allergies, Pre-existing conditions and Clinical Notes fields and will view the remaining fields.
All the other fields remain visible to the clinical officer, but grayed out.
How field-level permissions interact with other settings
Field-level permissions do not operate in isolation. Their behavior is closely tied to other form settings, such as:
Required fields
If a user does not have access to a field that is marked as required, they will not be able to add a new record, because the system cannot confirm if the required field has been completed.
An exception occurs when a default value is defined for the required field. In this case, the system can automatically populate the field, allowing the user to save the record even without direct access to it.
Validation rules and calculations
Validation rules and calculated fields depend on access to underlying field values.
If a user does not have View access to a field used in a validation rule or calculation:
- The system cannot evaluate the validation rule.
- Calculations depending on that field cannot be performed.
This is because the field is redacted, and therefore unavailable to the logic that drives validation or calculations.
Example: If a validation rule checks whether age must be greater than 18, but Date of birth field is redacted, the rule cannot be evaluated.
Design validation rules and calculations using fields that are accessible to the intended user roles, or ensure that redacted fields do not compromise critical form design.
Reports and saved analyses
Field-level permissions behave differently in the context of saved reports.
If a report is saved in the database and includes fields that are normally redacted for certain users, those users will still be able to view the fields within the report.
This behavior assumes that the report creator intentionally included those fields and wants them to be visible to users who can access the report. This is consistent with how role parameters function.
If report creators want to restrict access to sensitive fields in reports, they should consider:
- Saving reports in restricted folders.
- Limiting access to the report itself based on user roles.