Managing Users in Oracle Permitting and Licensing
This topic provides an overview of the types of users and describes how users are created and managed within the Public Sector Licensing and Permitting offering.
Overview of User Types in Oracle Permitting and Licensing
In the Public Sector Licensing and Permitting offerings, there are these types of users:
Anonymous Users
Registered Users
An anonymous user:
Accesses the site, but either has not registered with the application, or they have not signed in.
Could be an unregistered resident, a business owner, a contractor, and so on.
-
Can perform a limited number of basic tasks, such as access the public landing page, view transaction types, use a GIS map, self-register, run specific reports, and so on.
Registered users include:
Registered public user.
Agency staff member.
A registered public user:
Could be a resident, a contractor, a business owner, and so on.
Can access the registered user landing page, view their applications, apply for transaction types like permits, pay fees, manage their own user account, and so on.
An agency staff member:
Could be a permit technician, plan reviewer, plan coordinator, building inspector, and so on.
Can access the Agency Springboard, view assigned tasks, view all transaction types, plus they can access additional job-specific functions and data.
Creating Registered Public Users
When an unregistered user, clicks the Register button in the global header, and successfully completes the registration process, the application creates a user account for that user.
System administrators can define the information the anonymous user must provide during the registration process using the Public User Setup page.
For more information on the Public User Setup page, see Setting Up Public Users.
In addition to defining the options on the user registration page, system administrators can also define the roles that will automatically be assigned to the users upon registration using the Public User Roles page.
A registered public user would typically have a set of roles assigned to them, for example:
The PSC Registered Public User abstract role to provide all the default access for a resident, contractor, and so on.
The custom roles created during implementation to provide access to transactions, such as CUSTOM_PSC_MANAGE_PERMITS and CUSTOM_PSC_VIEW_PERMITS.
For more information on the Public User Roles page, see Setting Up Public User Roles.
For more information on the roles that need to be assigned to registered public users, see Creating Custom Roles for Oracle Permitting and Licensing
Creating Agency Staff Users
The agency staff user is employed by the agency in the capacity of administering or processing transactions, such as permit applications, planning applications, and so on.
You create agency staff users on the Agency Staff page, where you can create and manage the agency staff profile.
For more information, on the Agency Staff page, see Managing Agency Staff Profiles.
An agency staff member would typically have a set of roles assigned to them. For example, the following list illustrates a minimum set of roles:
The PSC Agency Staff abstract role to provide all the default access for an agency employee.
At least one of the delivered job roles, such as PSC Permit Technician, to provide access to the functions and data required to complete job tasks.
The custom roles created during implementation to provide access for job tasks, such as CUSTOM_PSC_MANAGE_PERMITS and CUSTOM_PSC_VIEW_PERMITS.
For more information on the roles that need to be assigned to various agency user types, see Creating Custom Roles for Oracle Permitting and Licensing.
Signing In
Depending on your identity provider platform, which could be Fusion or Oracle Identity Cloud Service (IDCS) the sign-in screen appears differently. You select your identity provider during licensing and implementation of the offering.
This example illustrates signing in using Fusion Security as your identity provider.
This example illustrates signing in using Oracle IDCS as your identity provider.
This example illustrates the prompt an anonymous user receives if they attempt to perform an action that requires specific credentials, such as accessing an intake form. The anonymous user can choose to sign in using their user ID or register in the system to obtain a user ID.
