A user’s permissions are based on two key items: the unit at which the permission was given and the level of permission given to a plan and its respective templates. Let’s talk about why these two areas matter when creating user permissions inside of Planning.
A campus site administrator is a universal setting inside of Planning given to a specific user(s) on campus that oversee the use and maintenance of the Planning application at the given institution. The site administrator setting allows a user to access all settings and data inside of Planning application. Unlike permissions, the site administrator setting only has two options, either the user is a site administrator or they are not.
This setting cannot be customized and privacy should be considered when setting a user as a site administrator.
After the site administrator level, Planning has 4 user access levels which are the following:
|No Access||No access is the lowest level of permission a user can have and denies them access to the template and any items created from the template.|
|Reviewer||The reviewer permission allows the user to access items created from a template with this setting in a read-only mode.|
|Contributor||The contributor permission allows a user to only add/edit content to a pre-existing item inside of Planning. The user does not have the ability to create new items from a plan template.|
|Administrator||The administrator permissions allow users to create items from a given plan template, as well as edit content of pre-existing items created within the unit by other users.|
When providing user permissions to a given unit in the organizational hierarchy it is important to know that these settings will be used by any child unit as well. This concept is known as inheritance. In the diagram below you can see how this works in practice. If I give user A permission at the unit of Demo University those settings are then inherited by every child of Demo University, as shown by the green arrows. If a unit does not have any child units, like Academic Affairs in the example below, then the settings for user B only apply to academic affairs, as Academic Affairs and Student Affairs are on the same level. Another example of this is shown with user C, where we assign them permissions to Student Affairs and then user C receives permissions to both Residence Life and Orientation.
When creating permissions for a user at a given unit, that user will be given the default permission settings for a Plan’s respective templates. In the screenshot below and to the left, you can see that for the template “Institutional Vision,” which belongs to the “Institutional Strategic Plan” that we have a default permission of “Administrator” set for the template. When adding a user, in this case, Michael Wisemen, to a given unit you will see that the permission level for the Institutional Vision template is set to “Admin” by default, matching what we have set for the template. I have also set the default permission for the remaining templates within the “Institutional Strategic Plan” to “Administrator” as well. When permissions for a user match across all templates with a plan you will see that permission setting displayed next to the plan name, in this case, we see “Administrator” displayed to the right of Institutional Strategic Plan. If we have a mix of settings for each template within a plan “Custom” will be displayed next to the plan name, informing the user adjusting permissions from a high level what the general theme of access is for a given user within a plan.
It is important to understand that default permissions are not retroactive. Default permission changes will only be applied when new users are added. When a default permission is changed it will only impact users added after the change and not those currently in the site. In order to adjust pre-existing user permissions, a site administrator or another user with the ability to manage users would need to adjust each user's permissions they wish to see the permission level change.
Just like unit access, plan and template access are also inherited. In the image below we can see that we have given User C permissions at the Student Affairs level for the Institutional Strategic Plan & provided “admin” permissions for each template, as per the defaults we have set up for the templates inside of this plan. Because these permissions are inherited, User C will have the same level of access to the templates within the Institutional Strategic Plan for the child units of Student Affairs, which is both Residence Life and Orientation. When permissions are inherited from parent units, you can only increase a users permission at the child level. You will not be able to set the permission lower at the child unit than what the parent unit has set. As an example, if the User C’s permissions were set to “No Access” at the parent (Student Affairs), I would be able to change that permission setting at child units, as I have three other levels to increase their permission to. However, because I have already set User C’s permission to its highest possible level at the parent, I am not able to change that at the child level. Permission can now only be changed at the parent.
These additional settings are not inherited and will need to be set per unit.
|Manage Users||Allowing a user to manage users provides them the ability to adjust plan and template permissions for the given organizational unit. This permission also allows a user to adjust the additional settings permissions for users.|
|This setting has three options:|
|Admin: allows users to access the report builder and displays the reports tab.|
|Viewer: allows users to only view reports built by a user with that ability and displays the reports tab.|
|No access: a user will not be able to create a report or view those created by others and that tab is hidden from view.|
|This setting has three options:|
|Admin: allows users to access the documents area and provides them access to create/edit pre-existing documents and folders and create new folders and documents.|
|Viewer: allows users to only view the documents area and prevents them from editing folders or documents.|
|No access: a user will be prevented from accessing the documents tab and hidden it from view.|
Permission Settings FAQ
What happens when a new plan & template is created or a new template added to a pre-existing plan?
- When a new template is added to a current plan or added to an existing plan, pre-existing users permission will be set to "no-access" by default and a site administrator or user with the ability to manage permissions will need to set permissions in order for them to use the template.