After this class, you will be able to: Identify and describe how permissions work in the system

1. 5.0 Permissions Overview & User Profiles • After this class, you will be able to: • Identify and describe how permissions work in the system • Understand the hierarchy of user settings • Know the contents of a user profile • Identify the roles of each user group • Determine which staff belongs in what user group

2. 5.0 Permissions Overview & User Profiles • Permissions • Permissions = Settings that control which users can view and or update content in the system. • Content that can be controlled by permissions include: • Forms, including ASI, TSI, and default system forms • Record type security, to limit access to particular records • Standard Comments • Conditions • Navigation- both menu and My Navigation • Consoles • Calendars • Queries • Reports • Inspections

3. 5.0 Permissions Overview & User Profiles • Permissions • Permissions = Settings that control which users can view and or update content in the system. • Content that can be controlled by permissions include: • Forms, including ASI, TSI, and default system forms • Record type security, to limit access to particular records • Standard Comments • Conditions • Navigation- both menu and My Navigation • Consoles • Calendars • Queries • Reports • Inspections • Fees and Payment (adding fees, voids, refunds) • Workflow • Sets • Batch processes (Expiration List and Letter process)

4. 5.0 Permissions Overview & User Profiles Permissions hierarchy Each user in the system falls belongs to a user group that belongs to a module. Permissions are set based on this same hierarchy in the system. Example Heidi Shamberger is a user in the system. She belongs to the BuildingAdmin user group. The BuildingAdmin user group belongs to the Building module. Heidi has access to certain items in her console, can update and view certain content for a record, can update and view certain reference libraries, and can perform certain supervisory functions, based on her permissions in the system.

5. 5.0 Permissions Overview & User Profiles What is a Module? Module = There are separate components in the Accela software that provide a focused service. Each module must be purchased and licensed separately from Accela. The Oregon ePermitting Program offers the “Building” module but Accela also offers Planning, Licensing, Public Works, etc. A user can belong to multiple modules in the system if your agency purchases additional modules from Accela. Permissions that are set at the Module level will affect all users within that module.

6. 5.0 Permissions Overview & User Profiles What is a User Group? User Group = Each module has individual user groups that determine the role a user will have. Each user can be associated to only 1 user group. Examples of user groups are BuildingReviewer, BuildingAdmin, BuildingInspector, BuildingPermitTech, etc. (Each user group begins with the word “Building” because they belong to the Building module. This helps organize the user groups.) Permissions that are set at the user group level will affect all users within that user group.

7. 5.0 Permissions Overview & User Profiles What is a User? User = Each person who logs into the ePermitting System will have their own user account. They are considered a “User”. Each user account has a profile with important information attached, including phone number, email address, inspector status, login credentials, password time out period, etc. The user profile also determines which add-on licenses the user has access to (AGIS and AMO), module, and user group they belong to. Permissions that are set at the user level will affect only that individual user. This is a less common way to set permissions. Most of the time, the permissions are set at a higher level.