This comprehensive guide explores the various permission scenarios associated with Multi-Modules, providing detailed insights and practical examples. It covers the different permission settings available and best practices for efficiently managing these permissions to enhance collaboration and security.
Naming and Description
Establishing a consistent naming convention can ease transitions at the district level, particularly during staff changes. It is recommended to standardize the following three practices:
1. Copy and rename the Default policy as outlined below, and archive Global Policies.
2. Use the following standard naming format:
IT | Name of Permission
Facilities | Name of Permission
Events | Name of Permission
HR | Name of Permission
Resources | Name of Permission
Change | Name of Permission
3. Additionally, provide a description for each permission to assist future users in understanding its purpose. Along with the permission name, include the date and the name of the user who made the last modification.
Scenario 1
Staff and faculty must log in to submit a ticket to IT/Facilities; however, they do not need the drop-down menu between modules. This setup will log the staff or faculty member into the IT side, but will provide them the choice to submit tickets to either IT or Facilities.
Create or reference the IT staff/faculty policy that permits the following actions: “login,” “submit ticket,” and “list users and view user list” (to enable submissions on behalf of another user).
Apply the "faculty" or "staff" role as necessary.
Next, switch to the Facilities side and remove the “faculty” and “staff” roles from the default permission policies.
Then, create a new Facilities Staff and/or Faculty policy that allows only the “submit ticket” option.
No Drop Down Toggle
Scenario 2
Facilities Agents need to log in to Facilities, submit tickets to both Facilities and IT, and view resolved work as designated. They will also have the toggle to IT but cannot access any IT-related content.
Begin by duplicating the "GLOBAL—AGENT ROLE PERMISSIONS" and renaming it to "Facilities | Base Agent Permissions" for the Facilities Agents team. We recommend including a description that indicates who last updated the policy and when it was updated.
Specify the condition related to the facilities teams or users to whom this policy applies. Do NOT use the role as a condition for granting access to Agents, as this will prevent IT agents from accessing Facilities tickets.
The base-level Facilities Team permissions should include the following items: “login,” “submit ticket,” “Ticket Access > View Tickets Nav Item,” and “List users and view users list” (to allow them to submit tickets on behalf of another user, if necessary).
Ensure that you communicate with the IT team before making any changes to the IT policy. Once you have confirmed any changes with the IT team, double-check that the out-of-the-box IT GLOBAL - AGENT ROLE PERMISSIONS have had the role removed.
Next, duplicate the "GLOBAL—AGENT ROLE PERMISSIONS" again and rename it "IT | Facilities Agent Login/Submit." On the IT side, ensure that you only grant them access to “login,” “submit ticket,” and “List users and view users list.” Specify the condition of the Agents. This approach will save them from needing to create and maintain a separate team on the Facilities side with the Facilities Agents.
Facilities Base Level Policy
IT Base Level Policy
Scenario 3
A team of Facilities agents needs to log in to the Facilities module without access to IT. If you prefer not to allow toggling between modules and want agents to have login ability only in the specific module they work in, follow these steps:
Complete the permissions policy setup on the Facilities side as described in Scenario 2.
Remove the “login” capability from the existing permission policy titled “IT | Facilities Agent Login/Submit.”
Rename the modified permission policy to “IT | Facilities Agent Submit Only.”
Scenario 4
You want Admins, Faculty, Staff, and Agents to have the ability to view Events.
All modules should have access to the Events section in the left navigation of each module.
A dedicated permission policy for Events is not necessary.
In the Ticketing module, create a policy named "Ticketing | View Events" and enable the appropriate permissions for either "View Events" or "Manage Events" and apply this policy to the relevant role, team, or users.