Aam Digital offers a configurable access control system to limit user permissions. Users can be assigned one or more roles that can limit permissions on various levels:

• limit access to selected types of data
  (e.g. restricting sensitive health or learning details)

• limit access to selected groups of records
  (e.g. allowing access only to beneficiaries at a specific location)

• limit access to selected documents
  (e.g. users can only access individually assigned notes)

• limit selected actions
  (e.g. allowing only coordinators to register new beneficiaries)

User management is based upon the Keycloak system, which offers options for integration with other single-sign-on providers, 2-factor-authentication and advanced authentication options.

also see:

• Data Security one-pager

• User Guide: Invite & Disable users

User Roles

A role defines a set of access rules that give users permissions regarding certain data records.

One role usually defines several rules that logically depend on each other. This keeps user management simple, as you only have to assign one (or very few) roles to each user.

(e.g. one role could give read-only access to all participant records and also permission to create and update notes).
for details about the available access rules, see below

Roles are assigned to individual user accounts. A user can also be assigned to multiple user permission roles. The permissions of each role are then combined to give that user access to the combination of all the roles’ access rights.

(e.g. a user could be assigned roles of “health worker” and “teacher”, giving access to health and education details for that account)

Access Rules

An access rule defines a subset of data and an allowed action that this user role is allowed to take on the given subset of data

Actions that can be granted/restricted are:

• create: add new data records

• read: access existing data records

• update: edit existing data records

• delete: completely remove existing data records

Subsets of data can be defined by a combination of:

• Entity type (e.g. Participants / Notes / Events / …)

• Value of a field of the record (e.g. participants with “gender” = “male”; events with “status” = “approved”)

  • (!) it is not possible to use “indirect values” for permissions (e.g. participants whose linked school is located in region X)

• Link to the current user (e.g. notes where the user is included in the “authors” field)

• Link to a “project” entity that the current user is added to (e.g. the user’s profile is linked to several “project” entities, participant records are also linked to a project entity, the user receives access only to those participants that are linked to the same project that the user account is linked to)

Example: Rules for approval workflow

Roles:

• manager

  • Access to all records

  • All actions (read / update / delete)

• fieldworker

  • Access to records linked to own user account

  • Allowed to create and read these records

  • Allowed to edit records only if the record’s “status” field is “to be reviewed”

Scenario / Workflow:
(exact fields and status categories below can be freely customized for your specific system)

1. fieldworker registers new participant.

   1. → creates new record in Aam Digital.

   2. “registered by” field of the new record is automatically pre-filled with a link to the user account. This gives the team clarity who recorded this data and grants the fieldworker continued access to this new record

   3. “status” field of the new record is automatically pre-filled to “to be reviewed”. This gives the manager an indication to check this record (and approve it) and allows the fieldworker to continue editing the record making corrections.

2. manager approves the new participant.

   1. → edits the record created by the field worker and checks the details.

   2. manager changes the “status” field to “approved”. This gives the team an indication that this record has been checked. The fieldworker can still see the record (he/she is still assigned in the “registered by” field)

   3. … but the fieldworker now cannot edit the information anymore (because the status is not “to be reviewed”). This ensures there are no accidental changes that contradict the approval.

3. … the manager at any time can also change the status of a record back to “to be reviewed”, which allows the fieldworker to again edit the record and make corrections until the manager changes the status again.