Structure

Hierarchy of a sample Education project 

Shown below is a slice of a defined Education project. You will notice 4 Levels namely Country, State, District, Site and Roles at each level. You can also add Customfields at each Level which can be viewed/updated from Workflows. For e.g., you will notice Population as a customfield added at State level. 

As we have discussed in the Configuration Introduction, Members are added at the lowest level in the hierarchy, which in this case, is the Site. You can add as many Levels per Project as you want. Do note that you cannot add/re-order levels as soon as the first Location is added under the Locations tab

Based on Hierarchy, you add Locations

Once you have finalised Levels for your Project, you need to add at least one set of Locations till the lowest level. Only then, will you be able to assign Login users to Locations and add Members at the lowest location level.

Define Roles within the Hierarchy

At every hierarchy level, you can add as many roles as you wish.  You can set Role level Thresholds and permissions to do Bulk Actions like Bulk Transfer of Workflows (from Workflows List page) and Export Sync Logs (from Users list page). In the example below, we are editing a role called Education Director at Country level and setting these Thresholds and Bulk Actions permission.

Based on Hierarchy and Roles, set Permissions

Now, that you have setup Locations and Roles, you can set permissions for each of those roles. The permission bits are of 3 types:

1. NONE - No access to the page/feature

2. READ - Can only READ the page or data within

3. WRITE - Can add, edit, export (wherever applicable) and archive the entity

Permission Types cover all of the Modules within the application from Structure till Languages. There are some important points to note, though:

1. Superuser (SU - Email account) has ALL permissions, by default

2. WRITE permission is required to create/add any entity like Member or Group. Say, you set Role, R1, permission on Member Type, MT1 as READ. User in Role, UR1, can ONLY VIEW data of already created Members and cannot add/edit such Members; WRITE permission is required to add/edit Members of type, MT1; Same applies to most other entities like Locations, Users, Groups, Workflows, Reports, Data and Languages 

3. To add/update any Configuration changes (via Configuration tabs) Users must have corresponding Configuration WRITE permissions; For e.g. say you want to allow Users in Role, UR1, to add/edit Member Type, MT1; Then the Role must be given permission to WRITE in General Type > Members Configuration  

4. Workflow permissions override Member/Group Type permissions; For e.g. you have a Workflow Type, WT1, which adds a Member of a Member Type, MT1. Say, Role1 has only READ access to MT1 but has WRITE access to WT1; Any user of Role1 can now add/edit Member of MT1 type (to which they have access) via the Workflow but NOT via the direct Add/Edit Member form. This is useful when you want to ensure Users can ONLY add/edit Members via Workflow

5. User roles can add/edit Languages by a combination of General Type> Languages Configuration permission and specific Language permission under Language Type > Selected Language permission; This way, you can create a Kannada specific Translator role and give them permissions to edit ONLY Kannada language phrases.