Overview  ↑

Field level security can currently be set up for Groups or Portal Groups. Field level security is used to deny (block) read and/or update rights to specific fields. Field level security is currently available for Student Data, Emergency Contacts, and Staff Data. Other areas may be added in the future. Field level security is not available when permissions are assigned directly to the user. Deny always takes precedence over any other permissions.


To set up field level security for a Group or Portal Group, click the Edit icon under the Fields column.



The following form will display. Permissions to the fields will default to On.



Setting Permissions   ↑

If the Group or Portal Group only has Read permission to the security area, the Field Security form will only display with a Read column. To Deny a field from being read, click the box under the Read column to change the green check mark to a red X. The members of this Group or Portal Group will no longer be able to read the data for this field on the Student Data form.



When Read permission is denied for a field, the user will see the text "N/A" instead of the field's value.



If the Group or Portal Group has Read and Update to the security area, the field security form will display Read and Update columns. To allow Read permissions for a field but deny Update permissions, leave a check mark in the Read column but in the Update column mark the box with a red X.


With these permissions, the members of the Group or Portal Group will be able to read the data on the form but will not be allowed to update the data in that field.


 

To deny both Read and Update permissions to a field, mark both the Read and Update boxes for the field with a red X. With these permissions, the members of the Group or Portal Group will not be able to read or update the specific field on the form.


 

NOTE: The permissions set on the field security form are saved automatically.


Users with denied Read permission to a field will not be able to Query that field. Query results for a denied field will display the field name instead of the actual data.


Important Clarification About Table‑Level and Field‑Level Permissions↑


Field‑level security in Aeries is hierarchical and works in conjunction with table‑level permissions.

Table‑level permissions act as the master control that determines whether field‑level permissions are applicable:

  • Field‑level permissions are subtractive only. They are used to deny Read and/or Update access to specific fields after those permissions have been granted at the table level.
  • If a Group or Portal Group does not have Read or Update permission granted at the table level, field‑level permissions for that action are considered not applicable.

Because of this design:

  • If Read permission is not granted at the table level, the Field Security form will not display Read permissions.
  • If Update permission is not granted at the table level, the Field Security form will not display Update permissions.
  • Field‑level Update permissions cannot be viewed or managed unless Update permission is first granted at the table level.

This behavior is intentional and ensures that permissions are applied consistently and securely. Denying access at the table level already prevents access to all fields, so additional field‑level denies would have no effect until table‑level permission is allowed.