2Managing Roles

Managing Roles in Public Sector Compliance and Regulation

This topic introduces roles are use to implement security and the general Oracle Cloud security role types. It also highlights key roles and configuration considerations to keep in mind when implementing Public Sector Compliance and Regulation.

Role-Based Access Control

When you receive your Oracle Cloud application, access to its functionality and data is secured using the industry-standard framework for authorization, role-based access control. In a role-based access control model, users are assigned roles, and roles are assigned access privileges to protected resources. The relationship between users, roles, and privileges is shown in the following figure.

This diagram illustrates that users inherit privileges and security policy by way of roles assigned to them, which is described in the text that follows.

Users gain access to application data and functions when you assign them roles, which correspond to the job functions in your organization or the functions a citizen in your municipality may perform.

Users can have any number of different roles concurrently, and this combination of roles determines the user's level of access to protected system resources. For example, a user might be assigned the Agency Staff role, the Permits Supervisor role, and the Permits Application Administrator role. In this case, the user has the following access:

• With the Agency Staff role, the user can access functions and data suitable for agency staff members.

• With the Permits Supervisor role, the user can access permits manager functions and data, and access and correct permit technician functions and data.

• With the Permits Application Administrator role, the user can access permit configuration settings and make necessary changes.

When the user logs into Oracle Cloud and is successfully authenticated, a user session is established and all the roles assigned to the user are loaded into the session repository. Oracle Cloud determines the set of privileges to application resources that are provided by the roles, then grants the user the most permissive level of access.

Role Types

Oracle Cloud defines the following types of roles:

Role Type	Description
Job Roles	Job roles represent the jobs that users perform in an organization. General Accountant and Accounts Receivables Manager are examples of predefined job roles. You can also create job roles.
Abstract Roles	Abstract roles represent people in the enterprise independently of the jobs they perform. Some predefined abstract roles in Oracle Applications Cloud include Employee and Transactional Business Intelligence Worker. You can also create abstract roles. All users are likely to have at least one abstract role that provides access to a set of standard functions. You may assign abstract roles directly to users.
Duty Roles	Duty roles represent a logical collection of privileges that grant access to tasks that someone performs as part of a job. Budget Review and Account Balance Review are examples of predefined duty roles. You can also create duty roles. Other characteristics of duty roles include: They group multiple function security privileges. They can inherit aggregate privileges and other duty roles. You can copy and edit them. Job and abstract roles may inherit duty roles either directly or indirectly. You don't assign duty roles directly to users.
Aggregate Privileges	Aggregate privileges are roles that combine the functional privilege for an individual task or duty with the relevant data security policies. Functions that aggregate privileges might grant access to include task flows, application pages, work areas, dashboards, reports, batch programs, and so on. Aggregate privileges differ from duty roles in these ways: All aggregate privileges are predefined. You can't create, modify, or copy them. They don't inherit any type of roles. You can include the predefined aggregate privileges in your job and abstract roles. You assign aggregate privileges to these roles directly. You don't assign aggregate privileges directly to users.

Duty Role Elements

Functional security privileges and data security policies are granted to duty roles. Duty roles may also inherit aggregate privileges and other duty roles.

Elements	Description
Data Security Policies	For a given duty role, you may create any number of data security policies. Each policy selects a set of data required for the duty to be completed and actions that may be performed on that data. The duty role may also acquire data security policies indirectly from its aggregate privileges. Each data security policy combines: A duty role, for example Expense Entry Duty. A business object that's being accessed, for example Expense Reports. The condition, if any, that controls access to specific instances of the business object. For example, a condition may allow access to data applying to users for whom a manager is responsible. A data security privilege, which defines what may be done with the specified data, for example Manage Expense Report.
Function Security Privileges	Many function security privileges are granted directly to a duty role. It also acquires function security privileges indirectly from its aggregate privileges. Each function security privilege secures the code resources that make up the relevant pages, such as the Manage Grades and Manage Locations pages. Tip: The predefined duty roles represent logical groupings of privileges that you may want to manage as a group. They also represent real-world groups of tasks. For example, the predefined General Accountant job role inherits the General Ledger Reporting duty role. To create your own General Accountant job role with no access to reporting structures, you could copy the predefined job role and remove the General Ledger Reporting duty role from the role hierarchy.

Aggregate Privileges

Aggregate privileges are a type of role. Each aggregate privilege combines a single function security privilege with related data security policies. All aggregate privileges are predefined. This topic describes how aggregate privileges are named and used.

• Aggregate Privilege Names

  An aggregate privilege takes its name from the function security privilege that it includes. For example, the Manage Accounts Payable Accounting Period Status aggregate privilege includes the Manage Accounting Period Status function security privilege.

• Aggregate Privileges in the Role Hierarchy

  Job roles and abstract roles inherit aggregate privileges directly. Duty roles may also inherit aggregate privileges. However, aggregate privileges can't inherit other roles of any type. As most function and data security in job and abstract roles is provided by aggregate privileges, the role hierarchy has few levels. This flat hierarchy is easy to manage.

• Use of Aggregate Privileges in Custom Roles

  You can include aggregate privileges in the role hierarchy of a custom role. Treat aggregate privileges as role building blocks.

• Creating, Editing, or Copying Aggregate Privileges

  You can't create, edit, or copy aggregate privileges, nor can you grant the privileges from an aggregate privilege to another role. The purpose of an aggregate privilege is to grant a function security privilege only in combination with a specific data security policy. Therefore, you must use the aggregate privilege as a single entity.

  If you copy a job or abstract role, then the source role's aggregate privileges are never copied. Instead, role membership is added automatically to the aggregate privilege for the copied role.

Understanding Role Hierarchies and Inheritance

Almost every role is a hierarchy or collection of other roles.

• Job and abstract roles inherit aggregate privileges. They may also inherit duty roles.

  In addition to aggregate privileges and duty roles, job and abstract roles are granted many function security privileges and data security policies directly. You can explore the complete structure of a job or abstract role in the Security Console.

• Duty roles can inherit other duty roles and aggregate privileges.

When you assign roles, users inherit all of the data and function security associated with those roles.

In Oracle Cloud, each role can be linked to other roles in a parent-child format to form a hierarchy of roles. As illustrated in the following figure, users are assigned job and abstract roles, which inherit duty roles and their associated privileges. Duty roles in turn can inherit privileges from subordinate duty roles. You can explore the complete structure of a job or abstract role on the Security Console.

This diagram illustrates the relationship between job roles, abstract roles, and duty roles, which is described in the text that follows.

Role hierarchies allow privileges to be grouped to represent a feature set in Oracle Cloud, which simplifies feature management. Role hierarchies also provide privilege granularity and facilitate role reuse. For example, each role hierarchy beneath the job role represents a feature that is available through the job role to the user. Roles at lower levels of the hierarchy represent functionality that the feature requires. If this functionality is required by other features, the role that provides the functionality can be shared across roles.

Note: Having many levels in a role hierarchy is not recommended. Deep role hierarchies are difficult to manage, and modification of the privileges in roles that are heavily reused can cause undesired consequences in other features.

This diagram illustrates a scenario of a user’s security roles and privileges and is described in the text that follows.

In the previous example, assume an inspection supervisor, Grady Parker.

• Because Grady is employed by the agency, he is assigned the Agency Staff abstract role, and at least one job role, which is in the is case Inspection Supervisor.

• Through the Inspection Supervisor job role, Grady inherits a set of duty roles, including the Inspection Request Management duty role. There is also a privilege unique to inspection supervisors, Access Supervisor Calendar, which is assigned directly to the job role.

• The Inspection Request Management duty role contains other duty roles as well as a set of inherited aggregate privileges, including Cancel Inspection Requests and Schedule Inspections.

• The Cancel Inspection Requests aggregate privilege is comprised of both a function security policy and data security policy.

Predefined Roles for Public Sector Compliance and Regulation

Public Sector Compliance and Regulation provides a set of predefined top-level roles that you can assign to users or clone to create additional roles. Oracle Cloud refers to the top-level roles in the system as top roles, because these are the roles at the top of the role hierarchy. Top roles can be job roles or abstract roles.

The following table lists a sample of the top roles in the Public Sector Compliance and Regulation offering.

Role	Role Type	Description
PSC Agency Staff	Abstract	Provides default privileges for any agency staff employee.
PSC Registered Public User	Abstract	Provides default privileges for any end user who has completed the self registration process.
PSC Building Inspector	Job	An agency staff position responsible for inspecting sites for permit approval.
PSC Business Analyst	Job	A staff member that supports the agency in implementing and maintaining the applications.
PSC Cashier	Job	Responsible for the sale and record keeping for various licenses and permits.
PSC Chief Building Officer	Job	Manages a staff of permit technicians and inspectors. Oversees that the staff processes permits expeditiously and accurately and that all fees are collected and accounted.
PSC Economic Development Officer	Job	Maintains various ledgers, registers, and journals according to established account classifications. Audits fees against department activity, researches discrepancies, and performs accounting clerical work.
PSC Finance Administrator	Job	Reviews all incoming permit applications for accuracy and checks for any needed supporting documentation. Reviews the checklist to determine if they need further review or routing to other departments.
PSC Geographical Information System Administrator	Job	Uses Geographical Information System software and related programs for provision of maps, charts, graphs, and other related information for visual displays, presentations or reports.
PSC Inspections Supervisor	Job	Manages the workflow and staff to get through inspection jobs everyday. Keeps track of inspectors, districts and workload.
PSC Permit Technician	Job	Performs permit technician duties, which includes processing applications, fee assessments, fee collections, documents, standardization, and permit issuance.
PSC Permits Application Administrator	Job	An agency staff position that oversees the permit application.
PSC Permits Supervisor	Job	Manages the workflow and staff to ensure that the permit applications are assigned and processed by the permit technicians.
PSC Plan Reviewer	Job	Reviews plans for development, modification, alteration and demolition of commercial and residential properties. Checks compliance with applicable state and local zoning and building codes and related regulations. Calculates fees required for issuance of permits.
PSC Planning Coordinator	Job	Coordinates plan review, permitting, and inspection of private construction projects in accordance with municipal ordinances and adopted building codes and code enforcement.
PSC Principal Planner	Job	Reviews construction plans for compliance with all state and local development and zoning codes, regulations, and requirements.
PSC System Administrator	Job	An agency staff position that has all access to configuration settings, security settings, and is able to access and solve issues for other users.
PSC Zoning Administrator	Job	Responsible for administering and enforcing the Planning Code. Provides written interpretations and clarifications of the Planning Code. Advises the Planning Director on amendments to the Planning Code. Monitors and maintains data related to the ongoing implementation of the Planning Code. Manages planners to ensure Planning and Zoning Code compliance.
PSC Associate Planner	Job	Prepares assessments on projects submitted for approval. Assists in the evaluation of projects submitted. Checks plans for zoning compliance.
PSC Principal Planner	Job	Reviews construction plans for compliance with all state and local development and zoning codes, regulations, and requirements.
PSC Planning Assistant	Job	Performs planning work involving the research, organization, and graphic presentation of zoning and planning data. Assists planners in compiling data, and assembling and distributing packets for board meetings.
PSC Planning and Zoning Application Administrator	Job	Administers, manages, configures the Planning and Zoning offering.
PSC Code Enforcement Application Administrator	Job	An agency staff position that oversees the Code Enforcement application.
PSC Code Enforcement Officer	Job	Enforces municipal code, follows the route to assigned cases, records notes and statuses, issues citations, records cases in the field if violations are found, researches history of address, parcel, owner, and past violations.
PSC Code Enforcement Supervisor	Job	Supervises, assigns, reviews, and participates in the operations and activities of an agency code enforcement program, including implementing activities related to setting and ensuring compliance with applicable ordinances, codes, and related regulations. The Supervisor ensures work quality and adherence to established policies and procedures, performs the more technical and complex tasks relative to assigned area of responsibility, and conducts field inspections and participates in hearings.
PSC Code Enforcement Technician	Job	Serves as a gatekeeper for all code enforcement incidents, assigns inspections to code officers, responds to direct communications, manages noticing procedures, and supports escalations where necessary.

The remainder of the delivered roles are lower-level child roles that group privileges and link privileges to the top-level roles.

Key Duty Roles in Public Sector Compliance and Regulation

The following table highlights a set of key duty roles to illustrate some delivered, predefined duty roles.

Duty Role	Description
PSC Apply Permit	Provides all the access required for an applicant, such as being able to access a permit, fill in and submit a permit application, add comments to the permit during the application process, and so on.
PSC Agency Permits Inquiry	Provides the read only access for the agency staff members so that they can review and process permit applications.
PSC Anonymous Permit Application Inquiry	Provides read-only access for viewing a permit application. Note: Oracle Fusion Applications do not allow modification of any anonymous roles.
PSC Apply Planning Application	Provides all the access required for an applicant, such as being able to access a planning application, fill in and submit a planning application, add comments to the planning application during the application process, and so on.
PSC Agency Planning Application Inquiry	Provides the read only access for the agency staff members so that they can review and process applications.
PSC Anonymous Planning Application Inquiry	Provides read-only access for viewing a planning application. Note: Oracle Fusion Applications do not allow modification of any anonymous roles.
PSC Report Code Enforcement Issue Duty	Provides all the access required for reporting an issue for Code Enforcement, such as being able to access issue subtype, fill in and submit an issue intake form, add comments to the report during the process, and so on.
PSC Agency Code Enforcement Case Inquiry	Provides the read only access for the agency staff members so that they can review and process cases.
PSC Agency Code Enforcement Incident Inquiry	Provides the read only access for the agency staff members so that they can review and process incidents.
PSC Anonymous Code Enforcement Incident Inquiry	Provides the read only access for anonymous users so that they can review reported incidents.

Working with Aggregate Privileges in Public Sector Compliance and Regulation

All aggregate privileges are predefined. Aggregate privileges combine a single functional security privilege with related data security policies.

In many cases with roles in the Public Sector Compliance and Regulation Cloud, you see a pattern, where one aggregate role provides the general, default behavior, such as allowing a user to insert comments and update only their own comments. Then there is a counterpart aggregate role that would provide more far reaching privileges, such as updating the comments for others.

For example, consider these aggregate roles:

• PSC Update Inspection Comments added by self

• PSC Update Inspection Attachments added by self

• PSC Update Inspection Comments added by others and self

• PSC Update Inspection Attachments added by others and self

For example, with the comments and attachments, most roles provide you with the ability to add comments or attachments and update comments or attachments inserted by yourself. However, by assigning to the user another aggregate role (with the phrase “by others and self” in the role title), that user could update comments or attachments added by others. A supervisor in the permit processing department could update comments in a permit added by one of their permit technicians if they have the following role assigned to their user account: PSC Update Inspection Comments added by others and self.

By default, the ”by others and self” aggregate privileges are assigned only to system administrators.

Modifying Delivered Roles

Caution: If you find you want to update a delivered role, it is not recommended to modify the role itself.

If the delivered top roles do not meet your business requirements, you can create custom roles by cloning a delivered job or abstract role, and then modifying the custom role as needed. When cloning a role, this also copies the role hierarchy, which you can modify as needed by either adding or removing elements of the hierarchy.

When creating custom roles, it is highly recommended to modify a role’s access through aggregate privileges, rather than attempting to modify a job, abstract, or duty role manually. Modifying access using aggregate privileges is efficient and a more robust approach. Keep in mind that aggregate privileges contain both the functional security and the data security policy for an action. By adding or removing an aggregate privilege, you make one change, but adjust both aspects of security simultaneously.

If you update a duty role manually, you will need to always make sure you’ve added or removed the functional and data security counterparts. Otherwise, you may not be providing or restricting the access you intend, while in other cases, you may be creating security holes, unintentionally.

Managing Data Security Policies

This topic provides an overview of data security and discusses concepts related to how you secure data by provisioning roles that provide the necessary access.

Comparing Function Security and Data Security

Function security is a statement of what actions you can perform in which user interface pages.

Data security is a statement of what action can be taken against which data.

Function security controls access to user interfaces and actions needed to perform the tasks of a job. For example, an accounts payable manager can view invoices. The Accounts Payable Manager role provisioned to the accounts payable manager authorizes access the functions required to view invoices.

Data security controls access to data. In this example, the accounts payable manager for the North American Commercial Operation can view invoices in the North American Business Unit. Since invoices are secured objects, and a data role template exists for limiting the Accounts Payable Manager role to the business unit for which the provisioned user is authorized, a data role inherits the job role to limit access to those invoices that are in the North American Business Unit. Objects not secured explicitly with a data role are secured implicitly by the data security policies of the job role.

Both function and data are secured through role-based access control.

Implementing Data Security

By default, users are denied access to all data.

Data security makes data available to users by the following means.

• Policies that define grants available through provisioned roles

• Policies defined in application code

You secure data by provisioning roles that provide the necessary access.

Note: Public Sector Compliance and Regulation does not employ the use of data roles.

When you provision a job role to a user, the job role limits data access based on the data security policies of the inherited duty roles. When you provision a data role to a user, the data role limits the data access of the inherited job role to a dimension of data.

Data security consists of privileges conditionally granted to a role and used to control access to the data. A privilege is a single, real world action on a single business object. A data security policy is a grant of a set of privileges to a principal on an object or attribute group for a given condition. A grant authorizes a role, the grantee, to actions on a set of database resources. A database resource is an object, object instance, or object instance set. An entitlement is one or more allowable actions applied to a set of database resources.

Data security features include:

• Data security policy: Defines the conditions in which access to data is granted to a role.

• Role: Applies data security policies with conditions to users through role provisioning.

The sets of data that a user can access are defined by creating and provisioning roles. Oracle data security integrates with Oracle Platform Security Services (OPSS) to entitle users or roles (which are stored externally) with access to data. Users are granted access through the privilege assigned to the roles or role hierarchy with which the user is provisioned. Conditions are WHERE clauses that specify access within a particular dimension, such as by business unit to which the user is authorized.

Data Security Policies

Data security policies articulate the security requirement "Who can do what on which set of data."

For example, accounts payable managers can view AP disbursements for their business unit.

A data security policy is a statement in a natural language, such as English, that typically defines the grant by which a role secures business objects. The grant records the following.

• Table or view

• Entitlement (actions expressed by privileges)

• Instance set (data identified by the condition)

For example, disbursement is a business object that an accounts payable manager can manage by payment function for any employee expenses in the payment process.

Note: Some data security policies are not defined as grants but directly in applications code. The security reference manuals for Oracle Fusion Applications offerings differentiate between data security policies that define a grant and data security policies defined in Oracle Fusion applications code.

A data security policy identifies the entitlement (the actions that can be made on logical business objects or dashboards), the roles that can perform those actions, and the conditions that limit access. Conditions are readable WHERE clauses. The WHERE clause is defined in the data as an instance set and this is then referenced on a grant that also records the table name and required entitlement.

Working with Database Resources and Data Security Policies

A data security policy applies a condition and allowable actions to a database resource for a role. When that role is provisioned to a user, the user has access to data defined by the policy. In the case of the predefined security reference implementation, this role is always a duty role.

The database resource defines an instance of a data object. The data object is a table, view, or flexfield.

The following figure shows the database resource definition as the means by which a data security policy secures a data object. The database resource names the data object. The data security policy grants to a role access to that database resource based on the policy's action and condition.

A database resource specifies access to a table, view, or flexfield that is secured by a data security policy.

• Name providing a means of identifying the database resource

• Data object to which the database resource points

Note: If the data security policy needs to be less restrictive than any available database resource for a data object, define a new data security policy.

Actions correspond to privileges that entitle kinds of access to objects, such as view, edit, or delete. The actions allowed by a data security policy include all or a subset of the actions that exist for the database resource.

A condition is either a SQL predicate or an XML filter. A condition expresses the values in the data object by a search operator or a relationship in a tree hierarchy. A SQL predicate, unlike an XML filter, is entered in a text field in the data security user interface pages and supports more complex filtering than an XML filter, such as nesting of conditions or sub queries. An XML filter, unlike a SQL predicate, is assembled from choices in the UI pages as an AND statement.

Note: An XML filter can be effective in downstream processes such as business intelligence metrics. A SQL predicate cannot be used in downstream metrics.

Creating Custom Roles for Public Sector Community Development

This topic describes how to create custom roles required to enable design-time and runtime access for various features of Public Sector Community Development offerings. These custom roles are required. They are not delivered, predefined roles. They must be created during implementation.

Creating Custom Roles Overview

In this task the following roles are created by the automated security setup process launched from Functional Setup Manager. The roles created depend on the offering you are implementing.

Note: The Role Category for Public Sector Compliance and Regulation roles is Financials - Job Roles. Public Sector Community Development services are a category of the Public Sector Compliance and Regulation solutions.

After the roles are created, you can then assign them to users (agency or public users) as described in the section, "Assigning Roles."

Running the Public Sector Security Setup Job to Create Custom Roles

You create the required custom security roles for your offering by completing the Run Public Sector Security Setup Process in the Initial Setup Functional Area of your offering in the Functional Setup Manager. The setup process is

To create Public Sector Compliance and Regulation custom roles:

1. Access Functional Setup Manager.

2. Select your offering in the Setup drop-down list.

3. Select the Initial Setup functional area.

4. Click the Run Public Sector Security Setup Process task.

   The page displayed enables you to launch an Oracle Enterprise Scheduler (ESS) process.

5. (Optional) Use the Process Options and Advanced buttons to set any desired settings.

6. Click Submit.

The following sections describe the roles required per offering and to which users they need to be assigned.

Common Custom Roles

Role Code	Role Name	Description
CUSTOM_PSC_REGISTERED_PUBLIC_USER	PSC Custom Registered Public User	Groups all the registered public user access privileges. This role requires the following child roles, depending on your offering. For Permits: CUSTOM_PSC_MANAGE_PERMITS CUSTOM_PSC_VIEW_PERMITS CUSTOM_PSC_APPLY_PERMITS_DATA For Planning and Zoning: CUSTOM_PSC_MANAGE_PNZ CUSTOM_PSC_VIEW_PNZ CUSTOM_PSC_APPLY_PNZ_DATA
CUSTOM_PSC_VIEW_ALL_APPLICATIONS	PSC View All Applications	Allows view access to all custom objects to agency staff. This role requires these child roles: CUSTOM_PSC_VIEW_PERMITS CUSTOM_PSC_VIEW_PNZ

Permits Custom Roles

Role Code	Role Name	Description
CUSTOM_PSC_MANAGE_PERMITS	PSC Custom Manage Permits	Allows users to apply for permits and update permits.
CUSTOM_PSC_VIEW_PERMITS	PSC Custom View Permits	Allows users to view the permit detail tab in the permits application.
CUSTOM_PSC_APPLY_PERMITS_DATA	PSC Custom Permit Applicant Data Access	Allows users to apply for permits and update their own permits in while in the status of pending.
CUSTOM_PSC_MANAGE_PERMITS_AGENCY	PSC Custom Permit Data Access for Agency	Allows users to apply for permits and update permits that have not been closed. This role requires these child roles: CUSTOM_PSC_MANAGE_PERMITS CUSTOM_PSC_VIEW_PERMITS

Planning and Zoning Custom Roles

Role Code	Role Name	Description
CUSTOM_PSC_MANAGE_PNZ	PSC Custom Manage Planning and Zoning Applications	Allows users to apply for Planning and Zoning applications.
CUSTOM_PSC_VIEW_PNZ	PSC Custom View Planning and Zoning Applications	Allows users to view Planning and Zoning applications.
CUSTOM_PSC_APPLY_PNZ_DATA	PSC Custom Planning and Zoning Applications Applicant Data Access	Allows users to apply for Planning and Zoning applications and update their own Planning and Zoning applications in pending status.
CUSTOM_PSC_MANAGE_PNZ_AGENCY	PSC Custom Planning and Zoning Applications Data Access for Agency	Allows users to apply for Planning and Zoning applications and update Planning and Zoning applications that are not closed. While creating the CUSTOM_PSC_MANAGE_PNZ_AGENCY role, add the following roles as child roles on the Role Hierarchy tab: CUSTOM_PSC_MANAGE_PNZ CUSTOM_PSC_VIEW_PNZ

Code Enforcement Custom Roles

Role Code	Role Name	Description
CUSTOM_PSC_CREATE_CE_INCIDENT	PSC Custom Create Code Enforcement Incidents	Allows users to create incidents.
CUSTOM_PSC_CREATE_CE_CASE	PSC Custom Create Code Enforcement Cases	Allows users to create cases.
CUSTOM_PSC_MANAGE_CE_AGENCY	PSC Custom Manage Incidents and Cases as CE Agency User	Allows agency users to manage cases and incidents. This role requires these child roles: CUSTOM_PSC_CREATE_CE_INCIDENT CUSTOM_PSC_CREATE_CE_CASE
CUSTOM_PSC_MANAGE_CE_ADMIN	PSC Custom Manage Incidents and Cases as CE Agency Admin	For system administration purposes for managing cases and incidents. This role requires these child roles: CUSTOM_PSC_CREATE_CE_INCIDENT CUSTOM_PSC_CREATE_CE_CASE This role requires these functional security privileges: FND_ADMINISTER_SANDBOX_PRIV ZCX_MANAGE_EXTENSIBLE_OBJECT_PRIV

Assigning Roles

You assign roles to users in the system using delivered setup pages. For public users, you use the Public User Roles page and for agency staff members, you use the Agency Staff Access page.

User Type	Role Assignments	Setup Page
Anonymous User	This is the default access available to all users, including users who have not signed in. You do not assign roles to this user type.	None.
Registered Public User	CUSTOM_PSC_REGISTERED_PUBLIC_USER	Public User Roles page
System Administrator	PSC Agency Staff PSC System Administrator CUSTOM_PSC_MANAGE_PERMITS_AGENCY CUSTOM_PSC_MANAGE_PNZ_AGENCY IT Security Manager Application Implementation Consultant Custom Objects Administration (This role will be available for assignment only after the first transaction type is created.)	Create the user with the Agency Staff page. Add roles using the Agency Staff Access page.
Business Analyst	PSC Agency Staff PSC Business Analyst CUSTOM_PSC_MANAGE_PERMITS_AGENCY CUSTOM_PSC_MANAGE_PNZ_AGENCY IT Security Manager Application Implementation Consultant Custom Objects Administration (This role will be available for assignment only after the first transaction type is created.)	Create the user with the Agency Staff page. Add roles using the Agency Staff Access page.
Branding Administrator	PSC Agency Staff PSC System Administrator CUSTOM_PSC_MANAGE_PERMITS_AGENCY CUSTOM_PSC_MANAGE_PNZ_AGENCY PSC Registered Public User IT Security Manager Application Implementation Consultant Custom Objects Administration (This role will be available for assignment only after the first transaction type is created.)	Create the user with the Agency Staff page. Add roles using the Agency Staff Access page. Note: Typically, it is not recommended to assign PSC Registered Public User to any of the agency staff users, including the administrators. This user configuration should be used only for completing branding activities, such as updating themes and menu navigation. If the same user is required to perform any of the other related transactions or setup, then the PSC Registered Public User role should be removed from the user.
Permits agency staff members	PSC Agency Staff CUSTOM_PSC_MANAGE_PERMITS_AGENCY CUSTOM_PSC_MANAGE_PNZ_AGENCY <Specific Job Role> (such as PSC Permit Technician, PSC Plan Reviewer, and so on)	Create the user with the Agency Staff page. Add roles using the Agency Staff Access page.
Planning and Zoning agency staff members	PSC Agency Staff CUSTOM_PSC_MANAGE_PERMITS_AGENCY CUSTOM_PSC_MANAGE_PNZ_AGENCY <Specific Job Role> (such as PSC Associate Planner, PSC Planning Assistant, PSC Zoning Administrator, and so on)	Create the user with the Agency Staff page. Add roles using the Agency Staff Access page.

Adding Roles to Agency Users for Creating Transaction Types

Users requiring administrative access to create transaction types, such as permit types or planning and zoning applications need to be assigned these roles:

• CUSTOM_PSC_MANAGE_PERMITS_AGENCY

• CUSTOM_PSC_MANAGE_PNZ_AGENCY

• ORA_CRM_EXTN_ROLE (This role will be available for assignment only after the first transaction type is created.)

• ORA_FND_IT_SECURITY_MANAGER_JOB

• ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB

Managing Custom Roles for Planning Application Access

This topic describes custom roles that need to be created for the Planning and Zoning service.

For information on the custom planning and zoning custom roles, see Creating Custom Roles for Public Sector Community Development.