1. Implementing Security
  2. Managing Users

1Managing Users

Managing Users in Public Sector Compliance and Regulation

This topic provides an overview of the types of users working in the permits and planning applications services, and describes how users are created and managed within Public Sector Compliance and Regulation.

Overview of User Types in Public Sector Compliance and Regulation

In the Public Sector Compliance and Regulation service, there are these types of users:

  • Anonymous Users

  • Registered Users

An anonymous user:

  • Accesses the permits site, but either has not registered with the application, or they have not signed in.

  • Could be an unregistered citizen, a business owner, a contractor, and so on.

  • Can access the public landing page, view all permit application types, use a GIS map, self-register, run specific reports, and so on.

Note: You do not create anonymous users or assign roles to them. For any user who is not registered and signed in, the application automatically assigns them the anonymous user role and privileges. The anonymous user role is a Fusion Applications role, and cannot be modified or cloned.

A registered user can be a:

  • Registered public user.

  • Agency staff member.

A registered public user:

  • Could be a citizen, a contractor, a business owner, and so on.

  • Can access the registered user landing page, view their applications, apply for permits and create planning applications, 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 permit application types, plus they can access additional job-specific functions and data.

Note: For the Public Sector Compliance and Regulation Cloud service, you do not create users through the Security Console interface. You create them using Public Sector Compliance and Regulation service pages described in the following sections.

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 citizen, 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 Public Sector Community Development.

Creating Agency Staff Users

The agency staff user is employed by the agency in the capacity of administering or processing permits and planning applications.

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 Public Sector Community Development.

Setting the Next URL for the Default User Category

This topic describes how to set the Next URL property for the default user category so that the current user is directed to the Public Sector Compliance and Regulation service after registering in the system and setting up user credentials and passwords.

This setup task only needs to be completed once for all users because all users are associated with the DEFAULT user category.

  1. Navigate to the Security Console.

  2. Select the User Categories tab.

  3. Click the DEFAULT user category link.

  4. On the DEFAULT User Category: Details page update the Next URL edit box to reflect the URL for your Oracle Public Sector Compliance and Regulation implementation.

    https://server.example.com/fscmUI/pscrAuthentication.html

  5. Save your changes.

Note: The URL entered using the previous steps, such as https://server.example.com/fscmUI/pscrAuthentication.html should only be used for setting the Next URL value.The URL that can be published for external public users is to access the service is: https://server.example.com/fscmUI/publicSector.htmlUsers can bookmark the URL for accessing the Public Sector Community Development homepage.

Setting Up Users for the Oracle Inspector Mobile Application

System administrators set up Oracle Inspector with profiles and security before they can implement the application on their mobile devices.

Before an inspector or agency staff can install, configure, and use the Oracle Inspector mobile application, you must do the following:

  • Create an agency staff profile for each user.

  • Configure security for each user.

  • Provide the users with the correct base URL for production.

Tip: Oracle recommends that agencies implement mobile device management (MDM) software to protect employees' mobile devices from security threats, such as malware and theft.

Creating an Agency Staff Profile

Make sure that each user has an agency staff profile to log into the mobile application. Because the application package configuration is secure, agency staff must enter their login credentials before the environment begins to download.

For more information about creating agency staff profiles, see the documentation for Managing Agency Staff Profiles.

Configuring Security

Agency administrators must explicitly grant mobile application access to the necessary agency user roles. Users can open the application but need the proper credentials. Make sure the appropriate users have one of the following roles assigned:

  • BUILDING_INSPECTOR

  • INSPECTOR_SUPERVISOR

For information about setting up roles, see the documentation for Managing Roles in Public Sector Compliance and Regulation.

Providing the Base URL for Production

Make sure you’re providing the users with the correct base URL for production. Implementation users need a test URL whereas agency staff must use the production URL in the field. See the instructions provided to inspectors and agency staff users about setting up the base URL in Installing and Configuring Oracle Inspector.

If needed, you can provide a new host URL, and users can reset the URL through the mobile application on the Reset Application URL page.