1Setting Up Workflow

Workflow Basics

You define your transaction workflow using the Process Builder in Oracle Autonomous Integration Cloud (OIC). This topic provides a general introduction to some important OIC terms and lists the high-level steps for setting up workflow for Public Sector Compliance and Regulation transactions. The list of steps includes links to additional specific information for this solution. Use this specific documentation in conjunction with the OIC documentation to learn how to set up workflow for Public Sector Compliance and Regulation.

To familiarize yourself with the Process Builder in OIC. see your OIC documentation at:https://docs.oracle.com/en/cloud/paas/integration-cloud/user-processes/develop-structured-processes.html.

Note: Oracle provides a Solution Package with sample workflow configurations for s. You can clone these samples and use them as starting points to create your own workflow. You can also set up your workflow from scratch.

Note: Currently, in the context of data object parameters, data association parameters, and REST resource attributes, the terms record, transaction, and permit are interchangeable.

Important OIC Terms

The OIC object where you set up your workflow tasks is called a process definition.

The following table describes the hierarchy of objects for a process definition. When you set up a type and you choose the appropriate process definition, you need to specify each of these hierarchical objects.

Object	Description
Space	Spaces are an organizational tool similar to a folder. Your agency chooses the spaces that make sense for your organization. For example, you can create separate spaces for different categories of s.
Application	Applications are functional areas within Spaces. Within an application, you can access a variety of features, including processes (workflow) and integrations. Certain configurations, including integrations and roles, are defined at the application level and shared by all of the application’s process definitions. Therefore, you can simplify the setup process by grouping related process definitions into a single application.
Version	When you activate a modified application to make it available for use, you choose a version number to assign. New and modified process definitions can’t be associated with a transaction type until you activate a version of the application that includes your changes. Caution: If you reuse the same version number when you activate an application, all open process instances using that version are terminated. To prevent this, use a new version number and then update any transaction types that need to use the new version.
Process Definition	A process definition is a specific workflow process. When different types have the same workflow, they can use the same process definition. See Reviewing a Sample Process Definition to walk through an example of a process definition for workflow.

High-Level Steps for Setting Up Workflow

The OIC documentation provides complete information on setting up workflow, but these are the high level steps, with some notes about product-specific considerations:

1. Set up a proxy role and user for accessing Oracle Integration Cloud.

   See Setting Up a Proxy Role and User for Oracle Integration Cloud.

2. Create the OIC space and application for your workflow.

3. Set up your transaction-specific integrations.

   See Setting Up the Communications Connector and Setting Up the Transactions Connector.

4. Create the process definition.

   Note: For Public Sector Compliance and Regulation workflow, you must create the process definition using the type Message.

5. Set up swimlanes.

   Swimlanes are equivalent to roles in the Public Sector system.

6. Design your process flow, which includes start and end events, human tasks, system tasks, gateway decision points, and arrows that define the flow through these objects.

   Your OIC documentation explains how to create a process flow, but there are additional considerations for Public Sector Compliance and Regulation. See Setting Up Process Definitions for Workflow for these important product-specific tasks:

   • Setting Up Transaction Data Definitions for a Process

   • Defining Arguments for the Start Event

   • Defining Data Associations for the Start Event

   • Defining Data Associations for Sending Notifications

   • Defining Data Associations for Sending Transaction Status Updates

   • Defining Data Associations for Retrieving Transaction Base Data

   • Defining Data Associations for Retrieving Transaction Field Data

   • Defining Data Associations for Retrieving Transaction Type Data

   • Defining Statuses (Outcomes) for Human Tasks

   • Defining Conditional Logic for Gateways

7. Use custom properties to add specific information to the human tasks in your workflow.

   See Using Custom Properties.

8. Activate your application and assign it a version number.

   Activating an application makes its new and modified process definitions available to associate with a transaction type. If you reuse the same version number when you activate the application, all open process instances using that version are terminated. To prevent this, use a new version number and update any impacted types so that they reference the new version number.

   Note: For applications used for the Planning and Zoning solution, activate the application with the Use Fault Policies option unchecked on the Activation Options page.

9. If this is the first time that the application has been activated, use the Manage Roles functionality in OIC to map swimlanes to roles.

   Swimlanes cannot be mapped until the application has been activated. The mapping applies to all process definitions in the application.

   See Mapping Workflow Swimlanes to Roles.

Managing Intersystem Connection Disruptions

There is a built-in mechanism for handling temporary unavailability of OIC. An automatic synchronization process runs every hour and scans a database table containing relevant information pertaining to any transaction, such as a , in the state of pending submittal. When the process discovers items in the table, it reconnects to OIC to retrieve the process instance for that transaction. After ten attempts, running once each hour, if reconnecting to OIC is not successful, the transaction becomes stale and manual intervention is required.

For example, if a registered user submits a application when OIC happens to be unavailable, that gets set to a state of pending submittal because no process instance can be associated with it due to OIC being unavailable. In that case, the system stores the information for that application in a specific database table, which will be discovered by the synchronization within an hour. Assuming OIC is available, the synchronization process retrieves the process instance from OIC, associates it with the application, and sets the transaction status to Submitted.

Reviewing a Sample Process Definition

A process definition provides a defined flow for processes such as the transaction lifecycle of a permit. This flow can include system tasks, human tasks, and decision gateways. You define your flow using the Process feature in Oracle Autonomous Integration Cloud (OIC). The Process feature provides a visual design environment to help you create easily understood workflow process definitions.

Note: Currently, in the context of data object parameters, data association parameters, and REST resource attributes, the terms record, transaction, and permit are interchangeable.

Let’s look a a sample process definition for a building permit.

This image shows the first half of the sample process, from the time the permit is submitted until it is issued.

The following table identifies the types of objects shown in the illustration:

Object	Description
Swimlanes	Horizontal bands in the process map represent the roles involved in the process.
Start and End Events	All paths through the workflow process must begin at the Start event and finish at the End event.
Human tasks	Green boxes with an image of a person represent tasks that are performed by humans.
System tasks	Blue boxes with an image of a cloud represent tasks that the system performs.
Gateways	White diamonds represent decision points, where the process flow can branch based on criteria you define.
Arrows	One-directional arrows define flows through the process. Gateways are the only objects that have multiple exit arrows. The exit arrow with a slash through it represents the default option after a gateway. All other exit arrows contain business logic for defining the conditions when the arrow is used.

With these definitions in mind, let’s look at the sample process flow:

1. Start: The process starts when a permit application is submitted, which sends a message to OIC to instantiate the workflow process.

2. Accept Application: A human performs the task of accepting the application and selecting a task status that represents the task outcome.

3. Get Permit Fields Data: This system task retrieves permit field data to be used later in the process, when it’s time to determine whether a plan review is required.

4. Application Decision: Exit arrows from this gateway determine the next step based on the outcome of the Accept Application human task.

   1. If more information is needed, the application acceptance task is reinstantiated. This loop continues until the task has a different outcome.

   2. If the application is rejected, a system task updates the permit status to Denied, then another system task sends the applicant an email notification that the permit was denied, then the process ends.

   3. If the outcome is anything else, the process continues.

5. Update Status = In Process: This system task updates the permit status to In Process.

6. Email - Application Accepted: This system task notifies the applicant that the permit was accepted.

7. Plan Review: Exit arrows from this gateway determine the next step based on the outcome of the Accept Application task and based on the job cost that was retrieved by the Get Permit Fields Data task:

   1. If the Accept Application outcome indicates that a plan review is required, or if the job cost is greater than 10,000, the Update Status = Plan Review system task updates the permit status to Plan Review, then a human completes the Complete Plan Review human task. When the Complete Plan Review is complete, the process continues.

   2. If a plan review is not required, the process continues.

8. Issue Permit: A human performs the task of issuing the permit and enters a task status that represents the task outcome (whether the permit was issued or rejected).

The following image shows the remainder of the sample workflow, after a human completes the Issue Permit task.

These steps describe the remainder of the workflow process, after the human task for issuing a permit:

1. Issue Permit: Exit arrows from this gateway determine the next step based on the outcome of the task for issuing a permit:

   1. If the permit is rejected, the Update Status = Denied This system task updates the permit status to Denied, then the Email - Permit Denied system task notifies the applicant that the permit was denied, then the process ends.

   2. If the outcome is anything else, the process continues.

2. Update Status = Issued Permit: This system task updates the permit status to Issued Permit.

3. Email - Permit Issued: This system task notifies the applicant that the permit was issued.

4. Get Permit Type Data: This system task retrieves permit type information for use in determining whether an inspection is needed.

5. Inspection: Exit arrows from this gateway determine whether an inspection is needed:

   1. If the permit type includes an inspection group, the Update Status = Inspection system task updates the permit status to Inspection. A human then completes the Approve Final Inspection task and enters the task outcome. The process then continues.

   2. If an inspection is not required, a human performs the Complete Permit task and enters the task outcome. The process then continues.

6. Update Status = Complete: this system task updates the permit status to Complete.

7. The process ends.

Setting Up a Proxy Role and User for Oracle Integration Cloud

Oracle Autonomous Integration Cloud (OIC) provides the tools for setting up workflow processes. This topic provides information about using the Security Console to set up a proxy user that the Public Sector system uses to access OIC.

In this procedure, create a user and assign the PSCR Proxy User for OIC (CUSTOM_PSCR_OIC_PROXY_USER) role to that user. You use the Security Console to complete this task. This user is the OIC proxy user that the OIC system uses to connect to Public Sector Compliance and Regulation to exchange data during transaction processing.

For more information about using the Security Console, see: Using the Security Console.

To create the OIC proxy user:

1. Navigate to the Security Console.

   To navigate to the Security Console, you have these options:

   • In Functional Setup Manager, click the task: Create Process Cloud Service Proxy User.

   • Click Setup and Maintenance on the Agency Springboard, and on the Fusion Applications home page, select Navigator > Tools > Security Console.

2. Click the Users tab.

3. On the Use Accounts page, click Add User Account.

4. On the Add User Account page in the User Information section, enter a Last Name and User Name of your choice.

   Note: The name given for the proxy user will be displayed on the Status History page of the transaction detail pages, for permits, planning applications, and so on. As such, you may want to use a generic name, such as System, Workflow, or something similar.

5. Enter a Password of your choice and confirm it.

6. Click Add Role for the Roles grid, and assign this role to your proxy user:

   • Role Name: PSCR Proxy User for OIC

   • Role Code: CUSTOM_PSCR_OIC_PROXY_USER

7. Click Save and Close.

Note: You will add this proxy user to OIC process definitions.

Setting Up the Communications Connector

The communications connector enables OIC to send data to the communications center in the Oracle Public Sector Compliance and Regulation system using a POST operation. This connector is used when a workflow process definition includes a communication task, such as sending a permit applicant an email when the permit status changes.

Oracle provides a Solution Package with sample integration configurations. You can clone these samples and use them as starting points for your own connectors. The instructions in this procedure explain how to set up the communications connector from scratch.

The following procedure explains how to set up the communications connector with the specific integration information that is required by the Public Sector system. For general instructions related to setting up integrations in OIC, refer to your OIC documentation at https://docs.oracle.com/en/cloud/paas/integration-cloud/user-processes/integrate-applications-and-services.html

Note: Before you set up the communications connector, you must create the Space and the Application for your workflow processes. See Workflow Basics.

Note: Currently, in the context of data object parameters, data association parameters, and REST resource attributes, the terms record, transaction, and permit are interchangeable.

To set up the communication connector:

1. Go to My Oracle Support, access Doc ID 2449735.1, Public Sector Compliance and Regulation: JSON Files for Transaction Integration, and download the following files that you will use later in this procedure:

   • RequestCommunications.json

   • ResponseCommunications.json

2. Access the main console in OIC.

3. In the list of OIC applications, click the application with your transaction workflow.

4. Click the Integrations option in the left frame.

5. Click the Create button, then in the pop-up menu under the Create button, select External > REST

6. In the Create REST Connector window, enter the following:

   Page Element	Description
   Name	Enter a descriptive name such as CommunicationsConnector. Note: The name CommunicationsConnector is suggested, however, you can choose your own name if needed.
   Base URL	Enter the URL for your Oracle Public Sector Cloud REST API resources. The URL follows this pattern, where ServerName is the server name for your instance of the application: https://ServerName/fscmRestApi/resources/11.13.18.05
   Open Immediately	Select this check box if it is not already selected.

7. Click Create.

   The Rest Connector Editor opens.

8. To set up security for this integration, click the Edit link for the Configuration section.

   Note: If you prefer to set up security when you activate the workflow application, you can skip the security-related steps in this procedure and skip ahead to step 13. Setting up security now simplifies the application activation steps.

9. Click the Security tab.

10. In the Security Type field, select APP Id - Basic Authentication.

11. Complete these additional fields that appear after you select the Security Type:

    Page Element	Description
    Keystore Credential	If you previously created a keystore credential, select it. Otherwise, leave this field set to [New Key] so that the system will create the keystore credential when you apply your changes.
    Key Name	If you selected [New Key] as the keystore credential, enter the name to give to the new keystore. If you selected an existing keystore credential, this field is read-only and displays the key name.
    Username	Enter the user name for the process cloud proxy user that you previously created. If you’re using an existing keystore credential, that credential supplies a default username.
    Password	Enter the password for the process cloud proxy user that you previously created. If you’re using an existing keystore credential, that credential supplies a default password.

12. Click Apply to save the security information and close the Configuration section.

13. In the Resources section of the Rest Connector Editor, click Add.

14. Expand the new Resource section that appears, and enter the following values:

    Field	Value
    Name	OutboundCommunications
    Path	publicSectorCommunicationRequests When added to the base URL, this completes the path to the communications-related REST APIs.

15. In the Operations section, click the Add button and then select POST operation from the drop-down menu.

16. Click the new POST operation.

17. Enter Trigger transaction communications in the Documentation field.

    You can leave the default values in the other fields, including leaving the Path field blank.

18. Click Request

19. Click the + icon next to the Body field to open the Import Business Object from JSON window.

20. Enter RequestCommunications in the Name field.

21. Click Schema.

22. Click the Import from File icon next to the Schema button.

23. Locate and upload the RequestCommunications.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

24. Click the Import button at the bottom of the window to save the code and close the window.

25. Ensure that the following values now appear for the POST operation request:

    Page Element	Value
    Body	BusinessData.RequestCommunications
    Media Type	Custom
    Media Type details	application/vnd.oracle.adf.resourceitem+json

26. Click Response.

27. Click the + icon next to the Body field to open the Import Business Object from JSON window.

28. Enter ResponseCommunications in the Name field.

29. Click Schema.

30. Click the Import from File icon next to the Schema button.

31. Locate and upload the ResponseCommunications.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

32. Click the Import button at the bottom of the window to save the code and close the window.

33. Ensure that the following values appear for the POST operation response:

    Page Element	Value to Enter
    Body	BusinessData.ResponseCommunications
    Media Type	application/JSON

34. Click Apply.

35. Click Save.

Setting Up the Transactions Connector

The transactions connector enables OIC to exchange transaction-related information with the Public Sector Compliance and Regulation system.

Oracle provides a Solution Package with sample integration configurations. You can clone these samples and use them as starting points for your own connectors. The instructions in this procedure explain how to set up the transactions connector from scratch.

The procedures that follow are for entering the specific information that is required by the Public Sector Compliance and Regulation system. For general instructions related to setting up integrations in OIC, refer to your OIC documentation at https://docs.oracle.com/en/cloud/paas/integration-cloud/user-processes/integrate-applications-and-services.html

Note: Before you set up connectors, you must create the Space and the Application for your workflow processes. See Workflow Basics.

Note: Currently, in the context of data object parameters, data association parameters, and REST resource attributes, the terms record, transaction, and permit are interchangeable. In some resource attributes, such as paths or parameters, trans is used in place of transaction for simplicity.

Procedure Overview for Setting Up the Transactions Connector

Setting up the Transactions Connector comprises multiple procedures with multiple steps. The following set of steps outline the high-level set of procedures involved with this task. Each item in the following list is explained in more detail in the following sections, in the listed sequence.

1. Download Required JSON Files for Workflow Integration Configuration

2. Create the Transactions Connector

3. Add the Transaction Resource

4. Add the PATCH Operation for Transaction Statuses

5. Add the GET Operation for Transaction Base Data

6. Add the GET Operation for Transaction Fields Data

7. Add the GET Operation for Transaction Data

8. Add the GET Operation for Transaction Assignee

9. Add the Transaction Type Resource

10. Add the GET Operation for Transaction Type Data

Step 1: Download Required JSON Files for Workflow Integration Configuration

For creating integrations from scratch, Oracle provides a set of JSON files for defining the integration between OIC and the Public Sector Compliance and Regulation system. Download all of the files first so that you can access them easily while completing the procedures documented in this topic.

To download the required JSON:

1. Sign on to My Oracle Support.

2. Access Doc ID 2449735.1, Public Sector Compliance and Regulation: JSON Files for Transaction Integration.

3. Download the following files to a local folder:

   • RequestTransStatusUpdate.json

   • ResponseTransStatusUpdate.json

   • ResponseTransBase.json

   • ResponseTransFields.json

   • ResponseTransData.json

   • ResponseTransAssignee.json

   • ResponseTransType.json

Step 2: Creating the Transaction Connector

Note: This procedure explains how to create the transaction connector. Additional procedures that follow this one explain how to set up the operations for this connector.

To set up the transactions connector:

1. Access the main console in OIC.

2. In the list of OIC applications, click the application for your workflow process.

3. Click the Integrations option in the left frame.

4. Click the Create button, then in the pop-up menu under the Create button, select External > REST

5. In the Create REST Connector window, enter the following:

   Page Element	Description
   Name	Enter a descriptive name, such as TransactionConnector. Note: The name TransactionConnector is suggested, however, you can choose your own name if needed. This documentation refers to TransactionConnector.
   Base URL	Enter the URL for your Oracle Public Sector Cloud REST API resources. The URL follows this pattern, where ServerName is the server name for your instance of the application: https://ServerName/fscmRestApi/resources/11.13.18.05
   Open Immediately	Select this check box if it is not already selected.

6. Click Create.

   The Rest Connector Editor opens.

7. If you want to set up security for this integration now, click the Edit link for the Configuration section.

   Note: If you prefer to set up security later when you activate the workflow application, you can skip the security-related steps in this procedure. Setting up security now simplifies the application activation steps.

8. Click the Security tab.

9. In the Security Type field, select APP Id - Basic Authentication.

10. Complete these additional fields that appear after you select the Security Type:

    Page Element	Description
    Keystore Credential	If you previously created a keystore credential, select it. Otherwise, leave this field set to [New Key] so that the system will create the keystore credential when you apply your changes.
    Key Name	If you selected [New Key] as the keystore credential, enter the name to give to the new keystore. If you selected an existing keystore credential, this field is read-only and displays the key name.
    Username	Enter the user name for the process cloud proxy user that you previously created. If you’re using an existing keystore credential, that credential supplies a default username.
    Password	Enter the password for the process cloud proxy user that you previously created. If you’re using an existing keystore credential, that credential supplies a default password.

11. Click Apply to save the security information and close the Configuration section.

12. Click Save

Step 3: Add the Transactions Resource

Note: Before starting this procedure, be sure to complete the procedure “Setting Up the Transactions Connector.”

1. Access the main console in OIC.

2. In the list of OIC applications, click the application for your workflow process.

3. Click the Integrations option in the left frame.

4. Click the TransactionConnector integration.

5. In the Resources section of the Rest Connector Editor, click Add.

6. Expand the new Resource section that appears, and enter TransactionResource in the Name field.

Step 4: Add the PATCH Operation for Transaction Statuses

Workflow in OIC uses the PATCH operation to update the status of a transaction.

To set up the PATCH operation:

1. In the Operations section of TransactionResource, click the Add button and then select PATCH operation from the drop-down menu.

2. Click the new PATCH operation.

3. Enter the following information:

   Page Element	Value
   Name	patchTransactionStatus
   Path	{transResource}/{transRecordKey} Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
   Documentation	Update transaction status.

4. Click Request

5. Click the + icon next to the Body field to open the Import Business Object from JSON window.

6. Enter RequestTransStatusUpdate in the Name field.

7. Click Schema.

8. Click the Import from File icon next to the Schema button.

9. Locate and upload the RequestTransStatusUpdate.json file that you downloaded from My Oracle Support.

   The imported JSON code appears in the Import Business Object from JSON window.

10. Click the Import button at the bottom of the window to save the code and close the window.

11. Ensure that the following values now appear for the PATCH operation request:

    Page Element	Value to Enter
    Body	BusinessData.RequestTransStatusUpdate
    Media Type	Custom
    Media Type details	application/vnd.oracle.adf.resourceitem+json

12. In each row of the Parameters list, click the Enter a description text and enter a description.

    These are example descriptions:

    Parameter	Description
    transResource	Transaction Resource Name
    transRecordKey	Transaction Record Key

13. Click Response.

14. Click the + icon next to the Body field to open the Import Business Object from JSON window.

15. Enter ResponseTransStatusUpdate in the Name field.

16. Click Schema.

17. Click the Import from File icon next to the Schema button.

18. Locate and upload the ResponseTransStatusUpdate.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

19. Click the Import button at the bottom of the window to save the code and close the window.

20. Ensure that the following values appear for the PATCH operation response:

    Field	Value
    Body	BusinessData.ResponseTransStatusUpdate
    Media Type	application/JSON

21. Click Apply.

22. Click Save.

Step 5: Add the GET Operation for Transaction Base Data

Note: Before starting this procedure, be sure to complete the procedure “Adding a PATCH Operation for Transaction Statuses.”

The getTransactionBaseData operation gets general transaction data that is found in all transactions, such as the permit type, the permit status, and the permit applicant for a permit transaction.

1. Expand the TransactionResource resource.

2. In the Operations section, click the Add button and then select GET operation from the drop-down menu.

3. Click the new GET operation.

4. Enter the following information:

   Field	Value
   Name	getTransactionBaseData
   Path	{transResource}/{transRecordKey} Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
   Description	Get base transaction data, such as applicant information

5. Click Request

6. In each row of the Parameters list, click the Enter a description text and enter a description.

   These are example descriptions:

   Parameter	Description
   transResource	Transaction Resource Name
   transRecordKey	Transaction Record Key

7. Click Response.

8. Click the + icon next to the Body field to open the Import Business Object from JSON window.

9. Enter ResponseTransBase in the Name field.

10. Click Schema.

11. Click the Import from File icon next to the Schema button.

12. Locate and upload the ResponseTransBase.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

13. Click the Import button at the bottom of the window to save the code and close the window.

14. Ensure that the following values appear for the GET operation response:

    Page Element	Value to Enter
    Body	BusinessData.ResponseTransBase
    Media Type	application/JSON

15. Click Apply.

Step 6: Add the GET Operation for Transaction Fields Data

The getTransactionFieldsData gets field data from the application intake form configured using the Intake Form Designer.

1. In the Operations section of the Transactions Resource, click the Add button and then select GET operation from the drop-down menu.

2. Click the new GET operation.

   The new GET operation has the default name of GetTransactionResources.

3. Enter the following information:

   Field	Value
   Name	getTransactionFieldsData
   Path	{transResource}/{transRecordKey}/child/FieldGroups Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
   Description	Get specific transaction data, such as job cost.

4. Click Request.

5. In each row of the Parameters list, click the Enter a description text and enter a description.

   These are example descriptions:

   Parameter	Description
   transResource	Transaction Resource Name
   transRecordKey	Transaction Record Key

6. Click Response.

7. Click the + icon next to the Body field to open the Import Business Object from JSON window.

8. Enter ResponseTransFields in the Name field.

9. Click Schema.

10. Click the Import from File icon next to the Schema button.

11. Locate and upload the ResponseTransFields.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

12. Click the Import button at the bottom of the window to save the code and close the window.

13. Ensure that the following values appear for the GET operation response:

    Page Element	Value to Enter
    Body	BusinessData.ResponseTransFields
    Media Type	application/JSON

14. Click Apply.

15. Click Save.

Step 7: Add the GET Operation for Transaction Data

The getTransactionData combines getTransactionBaseData and getTransactionFieldsData into a single operation, which you can use instead of using getTransactionBaseData and getTransactionFieldsData separately.

1. In the Operations section, click the Add button and then select GET operation from the drop-down menu.

2. Click the new GET operation.

   The new GET operation has the default name of GetTransactionResources.

3. Enter the following information:

   Field	Value
   Name	getTransactionData
   Path	{transResource}/{transRecordKey} Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
   Description	Combines getTransactionBaseData and getTransactionFieldsData into a single operation.

4. Click Request.

5. In each row of the Parameters list, click the Enter a description text and enter a description.

   These are example descriptions:

   Parameter	Description
   transResource	Transaction Resource Name
   transRecordKey	Transaction Record Key

6. Click Response.

7. Click the + icon next to the Body field to open the Import Business Object from JSON window.

8. Enter ResponseTransactionData in the Name field.

9. Click Schema.

10. Click the Import from File icon next to the Schema button.

11. Locate and upload the ResponseTransactionData.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

12. Click the Import button at the bottom of the window to save the code and close the window.

13. Ensure that the following values appear for the GET operation response:

    Page Element	Value to Enter
    Body	BusinessData.ResponseTransactionData
    Media Type	application/JSON

14. Click Apply.

15. Click Save.

Step 8: Add the GET Operation for Transaction Assignee

The getTransactionAssignee operation gets the assigned planner for transactions within the Planning and Zoning offering. You can configure subsequent tasks in the workflow process to reference the retrieved and stored getTransactionAssignee value.

1. In the Operations section, click the Add button and then select GET operation from the drop-down menu.

2. Click the new GET operation.

   The new GET operation has the default name of GetTransactionResources.

3. Enter the following information:

   Field	Value
   Name	getTransactionAssignee
   Path	publicSectorTransactionLatestAssignees/{transRecordKey} Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
   Description	Get specific transaction data, such as job cost.

4. Click Request.

5. In each row of the Parameters list, click the Enter a description text and enter a description.

   These are example descriptions:

   Parameter	Description
   transRecordKey	Transaction Record Key

6. Click Response.

7. Click the + icon next to the Body field to open the Import Business Object from JSON window.

8. Enter ResponseTransactionFields in the Name field.

9. Click Schema.

10. Click the Import from File icon next to the Schema button.

11. Locate and upload the ResponseTransAssignee.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

12. Click the Import button at the bottom of the window to save the code and close the window.

13. Ensure that the following values appear for the GET operation response:

    Page Element	Value to Enter
    Body	BusinessData.ResponseTransAssignee
    Media Type	application/JSON

14. Click Apply.

15. Click Save.

Step 9: Add the Transaction Type Resource

Note: Before starting this procedure, be sure to complete the previous procedures.

1. Access the main console in OIC.

2. In the list of OIC applications, click the application for your workflow process.

3. Click the Integrations option in the left frame.

4. Click the TransactionsConnector integration.

5. In the header of the Resources section, click Add to create a new transaction type resource.

6. Expand the new Resource section that appears, and enter the following information:

   Field	Value
   Name	TransactionTypeResource
   Path	publicSectorRecordTypes

Step 10: Add the GET Operation for Transaction Type Data

The GetTransactionTypeData operation gets data that is associated with the transaction type definition rather than with an individual transaction. For example, this operation can get the overall fee structure for a permit definition, because the fee structure is associated with the permit type.

To set up the GET operations for transaction type data:

1. In the Operations section of the Transaction Type Resource, click the Add button and then select GET operation from the drop-down menu.

2. Click the new GET operation.

3. Enter the following information:

   Page Element	Value
   Name	getTransactionTypeData
   Path	{transResource}
   Documentation	Get transaction type setup data.

4. Click Request

5. In the Parameters list, click the Enter a description text and enter a description.

   Here is an example description:

   Parameter	Description
   transResource	Transaction Resource Name

6. Click Response.

7. Click the + icon next to the Body field to open the Import Business Object from JSON window.

8. Enter ResponseTransTypeData in the Name field.

9. Click Schema.

10. Click the Import from File icon next to the Schema button.

11. Locate and upload the ResponseTransType.json file that you downloaded from My Oracle Support.

    The imported JSON code appears in the Import Business Object from JSON window.

12. Click the Import button at the bottom of the window to save the code and close the window.

13. Ensure that the following values appear for the GET operation response:

    Page Element	Value to Enter
    Body	BusinessData.ResponseTransTypeData
    Media Type	application/JSON

14. Click Apply.

15. Click Save.

Setting Up Process Definitions for Workflow

Workflow manages status updates throughout the transaction lifecycle and is an essential part of your setup. This topic provides information for creating your workflow process definitions.

Note: The procedures in this topic relate to the specific requirements of Public Sector Compliance and Regulations workflow. To create your workflow, you first need to become familiar with OIC and, in particular, the process builder in OIC. For more information, refer to your OIC documentation at https://docs.oracle.com/en/cloud/paas/integration-cloud/user-processes/develop-structured-processes.html

Note: Currently, in the context of data object parameters, data association parameters, and REST resource attributes, the terms record, transaction, and permit are interchangeable. The abbreviation trans is often used to represent transaction.

Setting Up Data Objects for a Process

Data objects provide a structure for storing data sent from the Public Sector Compliance and Regulation system. Every process definition that you create needs the same data objects, including:

• Simple string data definitions to store identifying information about the transaction and transaction type.

• Business object data definitions to store transaction base data, field data, and transaction type data.

  The data definition for fields includes all possible fields that can be added to an intake form, even though the transaction may use only a subset of fields that are appropriate for the type of transaction. Any fields that are not part of a specific transaction type remain blank when the workflow process retrieves the field data.

You must set up your data objects before you continue to this topic’s additional procedures for defining data associations.

Note: Before you set up your data objects, you need to set up the transaction connector for the application. This is because the transaction connector’s GET operations provide the underlying schema for the data. Setting up the transaction connector is described in the topic Setting Up the Transactions Connector.

To set up data objects for a process definition:

1. Access the process definition in OIC.

2. Click Data Objects.

3. Set up the data definition for transaction base data:

   1. In the Data Objects window, click Add.

   2. In the Create Process Data Object window, enter the following information:

      Page Element	Value
      Name	transactionBaseData
      Data Type	Business
      The drop-down list for data types	BusinessData.ResponseTransBase

   3. Click Create to create the data definition and return to the Data Objects window.

4. Set up the data definition for transaction field data:

   1. Click Add.

   2. Enter the following information:

      Page Element	Value
      Name	transactionFieldsData
      Data Type	Business
      The drop-down list for data types	BusinessData.ResponseTransFields

   3. Click Create.

5. Set up the data definition for transaction type data:

   1. Click Add.

   2. Enter the following information:

      Page Element	Value
      Name	transactionTypeData
      Data Type	Business
      The drop-down list for data types	BusinessData.ResponseTransType

   3. Click Create.

6. Click Close to close the Data Objects window.

7. Click Save.

Creating a Data Object to Store Start Event Arguments

In the next task you will define the start arguments for the Start event. In this procedure, you create the structure to store the arguments.

This procedure involves:

• Creating a business type using the business object option.

• Creating a data object and associating it with the business object.

To create the data object for start event arguments:

1. Open the process definition.

2. Select Business Types from the left panel.

   Note: Notice the other business types created automatically when importing the downloaded JSON, such as ResponseTransactionData.

3. Click Edit in the header, which causes the Create button to appear.

4. Click Create, and select New Business Object.

5. On the Create Business Object dialog box, enter the business object name, such as InitTransaction, and select the Parent Module as BusinessData.

6. Click Next.

7. Use the Add Attribute button to add these string data types to the business object.

   Attribute Name	Data Type
   transactionKey	String
   transactionType	String
   externalBaseURL	String
   resourceName	String
   transactionOwner	String
   transactionId	String
   classification	String
   subclassification	String

8. Click Finish.

9. Return to your process definition diagram.

10. Click the Data Objects button.

11. Click Add.

12. On the Create Process Data Object dialog box, make these changes:

    Field	Value
    Name	transaction
    Data Type	Business
    drop-down list	BusinessData.InitTransaction

13. Click Create.

This example illustrates the expanded transaction business data object, with the required string data within it.

Defining Arguments for the Start Event

When a transaction, such as a permit intake application, is submitted, the software instantiates that transaction’s workflow process by passing parameters, such as the transaction ID, to OIC. The Start event in your process diagram must have arguments defined for these parameters.

To set up the arguments for the start event:

1. Select the Start event in the process definition.

2. Click the Start event, and select Open Properties.

   The default view is the General section of the Implementation Properties.

3. In the How do you want to implement it? section, select Define Interface as the Type.

4. Click the pencil icon next to the Type field to open the Configure window.

5. Enter an operation name, such as start.

6. Add the following rows to the Arguments Definition.

   1. Use the Add button to add these strings using the values in this table, where each row represents a separate argument you need to create:

      Name	Type
      TransactionKey	string
      TransactionType	string
      ExternalBaseURL	string
      ResourceName	string
      TransactionOwner	string
      TransactionId	string
      Classification	string
      Subclassification	string

      Note: Arguments added to the Start event must be named exactly as documented.
      Note: You need to complete the output data association if you want the argument values stored in a Data Object.

   2. Click OK.

7. Close the properties panel and click Save.

Defining Data Associations for the Start Event

The data associations for the Start event capture identifying information about the transaction for initiating the process instance.

In this task, you map the arguments for the Start event to the data object values you entered for the transaction object.

To set up the data associations:

1. Open the process definition and select the Start event.

2. Click the Data Association button.

3. Set up the following data associations, mapping the Start event arguments to the appropriate attributes in transaction business object.

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   TransactionKey	transaction.transactionKey	The transaction ID.
   TransactionType	transaction.transactionType	The transaction type ID.
   ExternalBaseURL	transaction.externalBaseURL	The URL for the Public Sector Compliance and Regulation system.
   ResourceName	transaction.resourceName	The name of the REST API resource.
   TransactionOwner	transaction.transactionOwner	The owner of the transaction.
   TransactionId	transaction.transactionId	The transaction ID.
   Classification	transaction.classification	The classification of the transaction.
   Subclassification	transaction.subClassification	The subclassification of the transaction.

   This example illustrates mapping the Start event arguments to the associated data attributes in the transaction business object.

   

4. Click Apply.

5. Click Save.

Defining Data Associations for Sending Notifications

The data associations for a notification task define the information that the task sends to the public sector communications center.

Note: Create your email templates in the communications center before you set up integration for notification workflow tasks.

For more information about the communications center, see Setting Up Communication Events.

To set up the data associations:

1. Access the process definition and select the system task.

2. Click the Data Association button.

3. Set up the following input data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   [event name] For example, "LNP_WORKFLOW_001"	body.eventCode	The event as defined in the Communications Center in the public sector system. The source data string must be in quotation marks, and it must exactly match the identifier of an event. Oracle delivers these communication events, <Offering>_WORKFLOW_001 through <Offering>_WORKFLOW_005. Where “Offering” refers to your offering code, such as LNP for Permits or PNZ for Planning and Zoning.
   [template name] For example, "Application_Accepted"	body.templateCode	The identifier for the template to be used for the email. The source data string must be in quotation marks, and it must exactly match the name of a template in the transaction application.
   "LnpRecordKey"	body.recordFirstKeyName	The name of the key field.
   transaction.transactionKey	body.recordFirstKeyValue	The transaction ID.
   true or false	body.email	This Boolean field indicates whether the notification is sent as an email. Enter true only if the template is an email template.
   true or false	body.notification	This Boolean field indicates whether the notification is sent as an in-product notification. . Enter true only if the template is an in-product notification template.

   Caution: Templates are associated with either email or in-system notifications. Be sure to set up the body.email and body.notification values properly. Exactly one of the values must be true. If you want to send both types of notifications, you need to create two notification tasks.

4. Click Apply.

5. Click Save.

Defining Data Associations for Sending Status Updates

The data associations for a status update task define the information that the task sends to the Public Sector Compliance and Regulation system.

To set up the data associations:

1. Access the process definition and select the system task that updates the transaction status.

2. Click the Data Association button.

3. Set up the following input data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   transaction.resourceName	resourceName	The unique system identifier for the transaction type.
   transaction.transactionKey	transactionKey	The transaction ID
   [new transaction status] For example: "Accepted"	body.status	The status to be assigned to the transaction. The source data string must be in quotation marks, and it must exactly match one of the valid statuses for the transaction application.

4. Click Apply.

5. Click Save.

Defining Data Associations for Retrieving Transaction Base Data

The data associations for a task that retrieves transaction base data provides a structure for storing the retrieved data. In this task you create both input and output data associations.

To set up the data associations:

1. Access the process definition, and select the system task that retrieves transaction base data.

2. Click the Data Association button.

3. Set up the following input data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   transaction.resourceName	Resource	The unique system identifier for the transaction type.
   transaction.transactionKey	TransactionKey	The transaction ID

4. Click Output.

5. Set up the following output data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   body	BaseData	This business object contains all of thebase data. Mapping individual fields would be much more complex and is not necessary.

6. Click Apply.

7. Click Save.

Defining Data Associations for Retrieving Transaction Field Data

The data associations for a task that retrieves transaction field data provides a structure for storing the retrieved data. In this task you create both input and output data associations.

To set up the data associations:

1. Access the process definition, and select the system task that retrieves transaction field data.

2. Click the Data Association button.

3. Set up the following input data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   transaction.resourceName	transactionResource	The unique system identifier for the transaction type.
   transaction.transactionKey	TransactionKey	The transaction ID.

4. Click Output.

5. Set up the following output data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   body	transactionFieldsData	This business object contains all of the transaction fields. This includes all fields that can be included on the application intake form, whether or not the field exists for a specific transaction. Individual fields are nested within the items object. You can’t expand the items object on this page, but they are available in the expression editor that you use when creating business logic based on transaction data. Mapping individual fields would be much more complex and is not necessary.

6. Click Apply.

7. Click Save.

Defining Data Associations for Retrieving Transaction Type Data

The data associations for a task that retrieves transaction type data provides a structure for storing the retrieved data. In this task you create both input and output data associations.

To set up the data associations:

1. Access the process definition, and select the system task that retrieves transaction type data.

2. Click the Data Association button.

3. Set up the following input data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   transaction.resourceName	transactionResource	The unique system identifier for the transaction type.

4. Click Output.

5. Set up the following output data associations:

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   body	transactionTypeData	This business object contains all transaction type fields.

6. Click Apply.

7. Click Save.

Defining Statuses (Outcomes) for Human Tasks

The Action property for a human task lists the possible outcomes of the task. The actions you define appear as values in the Task Status drop-down list box on the Workflow page where agency staff manages workflow tasks. When the task status is updated on the Workflow page, OIC recognizes it as the task outcome and continues to the next step or gateway.

To define status values representing the outcomes of human tasks:

1. Access the process definition and select the human task.

2. Open the task properties.

3. In the Action field, enter a comma-delimited list of status values.

   Do not put a space before or after the comma. For example, if the status are Accept, Reject, and More Information, enter Accept,Reject,More Information in the Action field.

4. Close the properties window and save.

Defining Conditional Logic for Gateways

In a process map, gateways represent decision points where there is a branch in the process flow. The logic for taking different paths after the gateway is associated with the arrows to the possible subsequent tasks.

An arrow that represents a default branch does not require any logic.

For all other arrows, you need to set up the conditions under which the branch is used. To do this:

1. Access the process definition and select the arrow.

2. Click the pencil icon for the arrow to open the arrow properties.

3. Select the Conditional Flow check box.

   This check box is selected for all arrows other than the default arrow after a gateway.

4. Click the pencil icon for the Condition field.

5. Use the Expression Editor window to specify the conditions for using this branch.

   The Data Objects tab provides access to the data elements that you can evaluate. Transaction field data (the data from the intake form) is nested within the items element under TransactionFieldsData.

   In expressions that look for an exact match, take extra care with the spelling, capitalization, and punctuation of values that the expression evaluates.

6. Select the gateway and open the gateway properties.

7. Use the Order property to specify the order in which the previous task’s outcomes are evaluated for purposes of determining which arrow to follow.

Configuring a Planning and Zoning Human Task to Reference the Assigned Planner Value

If you want to assign the user to a human task, you need to have first setup the Transaction Connector to use the getTransactionAssignee operation.

For more information on setting up the Transaction Connector, see Setting Up the Transactions Connector.

To associate the transaction assignee data to your workflow process:

1. When configuring the workflow process data object, create a data object to store the output of the service call to getTransactionAssignee.

2. Locate the first human task in the process after the service call (Start event), and open the Data Association interface.

3. On the Input Data Association, map the assignee data object to execData.customAttributes.customAttributeString1.

4. For subsequent human task to which you want to reference the assigned planner, set the Assignee(s) value in the General Properties to customAttributes.customAttributeString1.

   1. Open the properties for the human task.

   2. Select Implementation > General.

   3. Click the Edit icon for the Assignee(s) field.

   4. Select Names and Expressions in the Build a list of participants using list.

   5. Click Add for the List Assignees edit box.,

   6. Select Add User.

   7. Click in the Data Type column, and select By Expression.

   8. Click the fx button in the Value column, and select customAttributes.customAttributeString1.

   9. Click OK.

   This example illustrates the settings on the List assignees who receive the task window.

   

5. Click Save.

Using Custom Properties

When you set up workflow, a variety of custom properties are available for implementing various features. This topic describes how use the custom properties.

These custom properties are available for workflow and are described in more detail below:

Property	Usage	Values
PSC_LIST_ORDER	Use this property to set the order for human tasks when there are multiple possible paths through the process definition. The order does not affect the workflow process, but it allows users to see the possible future workflow tasks in a logical order.	Integers For example: PSC_LIST_ORDER: 2
PSC_FINAL_ACTIVITY	Use this property to identify a human task that is not allowed to progress when the transaction has a condition that applies the Prevent Issue or Final business rule. In particular, use this property to identify the final human task in the process definition. See Setting Up Conditions and Applying Conditions to Applications.	Yes identifies the final activity. A blank value or a No value means that the task is not the final activity. For example: PSC_FINAL_ACTIVITY: Yes
PSC_ACTIVITY_TYPE	Use this property to identify the final inspection task in the process. Setting this property is necessary to support the transaction business logic that auto-advances the inspection task when the last inspection is closed.	Inspection is the only value with related business logic. Leave this property blank for other types of activities.
PSC_AUTO_UPDATE_ACTION	Use this property to identify the action to take when auto-advancing the final inspection task in a process. Setting this property is necessary to support the transaction business logic that auto-advances the inspection task when the last inspection is closed. Note: Security roles related to the Mobile Inspector app and the Plan Reviewer should be included in the task swimlane mapping.	The exact action name as specified in the Action property for the human task. Take extra care with the spelling, capitalization, and punctuation of the action name. For example: PSC_AUTO_UPDATE_ACTION: Approve
PSC_UNRESTRICTED_ACTIONS	Identifies actions that can be taken for the task even if there is logic preventing the task from advancing. Use this property when the task includes possible outcomes that return to a previous task rather than advancing. For example, if the final inspection can be advanced with an action of “Approve” or returned with an action of “Needs More Information,” then use the PSC_UNRESTRICTED_ACTIONS property to make “Needs More Information” an unrestricted action. This allows users to take the “Needs More Information” action, even though the logic that prevents the final inspection task from advancing disallows other actions. Currently, the PSC_UNRESTRICTED_ACTIONS property is applicable only for the Inspection action, as identified by the PSC_ACTIVITY_TYPE.	When there are multiple unrestricted actions, separate the actions with commas but no spaces. This is the same format used in the Actions property where you define all of the available actions for a human task. For example: PSC_UNRESTRICTED_ACTIONS: Needs more Info, Proceed, OK

Making Custom Properties Available in a Process Definition

Before you can use a custom property, you need to add the property to the process definition. You must do this for each of your process definitions.

To add a custom property to a process definition:

1. Access the process definition and click the # (Custom Properties) toolbar icon.

2. Enter the following values in the Property Name and Description fields in the Custom Properties list:

   Note: You must use the exact property names given in this procedure. You can, however, alter the descriptions.

   Property Name	Description
   PSC_LIST_ORDER	Human tasks display order
   PSC_FINAL_ACTIVITY	Identify the final human task
   PSC_ACTIVITY_TYPE	Identify the type of activity such as inspection
   PSC_AUTO_UPDATE_ACTION	Identify the action to take when auto-advancing

3. Click OK.

4. Click Save.

PSC_LIST_ORDER Property

The Workflow page for a permit includes an option to view a list of all past, present, and not started human tasks for the permit. The list displays past and present tasks in chronological order. However, the chronology for tasks that haven’t been started is not necessarily fixed. The branching logic in a process means that some tasks might be omitted or might occur in a different order depending on permit data or on the outcome of previous tasks.

To control the order in which not started human tasks appear, use the PSC_LIST_ORDER custom property. On the Workflow page’s list view, tasks that have not yet started are listed in the order you specify. If multiple not started tasks have the same number, they appear in the list in random order.

To assign order numbers to human tasks:

1. Analyze all human tasks in the process and decide on the appropriate order.

   Tasks appear in ascending numerical order. You assign order numbers one task at a time, so if you later decide to change the order, you have to update each affected task individually.

2. Access the process definition.

3. Select a human task.

4. Open the task properties.

5. Select the Business Properties icon in the icon bar, then select Custom Properties from the list of options that are associated with that icon.

6. Enter a number in the PSC_LIST_ORDER custom property.

7. Close the Properties window and save.

8. Repeat the previous steps for all human tasks in the process definition.

9. Click Save.

PSC_FINAL_ACTIVITY Property

Human tasks that you identify as a final activity cannot advance when a permit has a condition that applies the Prevent Issue or Final business rule.

To identify the final human task using the PSC_FINAL_ACTIVITY property:

1. Access the process definition.

2. Select the final human task.

3. Open the task properties.

4. Select the Business Properties icon in the icon bar, then select Custom Properties from the list of options that are associated with that icon.

5. Enter Yes in the PSC_FINAL_ACTIVITY custom property.

   To remove a Yes value from this property, set the value to No or clear the value and leave it blank.

6. Close the Properties window and save.

7. Click Save.

PSC_ACTIVITY_TYPE and PSC_AUTO_UPDATE_ACTION Properties

Permit processing includes logic to automatically progress past the final inspection step in the process definition when permit inspections are complete. To enable this functionality, you must identify the final inspection task in the process definition using the PSC_ACTIVITY_TYPE custom property. Further, you must identify the workflow action to apply to that task using the PSC_AUTO_UPDATE_ACTION custom property.

To set up custom properties for auto-advancing an inspection task:

1. Access the process definition.

2. Select the human task that represents final inspections.

3. Open the task properties.

4. Select the Business Properties icon in the icon bar, then select Custom Properties from the list of options that are associated with that icon.

5. Enter Inspection in the PSC_ACTIVITY_TYPE custom property.

6. Enter the desired action in the PSC_AUTO_UPDATE_ACTION custom property.

   The action you enter is the action to be taken when the task is successfully complete—that is, when the permit passes its final inspection. Take care to use the correct spelling, capitalization, and punctuation for the action name.

7. Close the Properties window and save.

8. Click Save.

Mapping Workflow Swimlanes to Roles

This topic describes how to assign security roles to the swimlanes in your workflow process definition.

In workflow process definitions, swimlanes represent roles. After the OIC application containing the process definition is activated, use the Manage Roles functionality in OIC to map the swimlanes to roles. The mapping applies to all process definitions in the OIC application.

A swimlane is typically associated with security roles, and it can be associated with multiple roles if needed. It can also be associated with one or more individual users if that approach is more applicable. A swimlane determines who is responsible for carrying out a task.

For example, if a swimlane is for plan review, you would add the PSC Plan Reviewer role to that swimlane. Likewise, if another swimlane is for inspecting, you would add all the roles that apply to that swimlane, such as PSC Building Inspector and any roles related to the Mobile Inspector app.

Note: When supervisors assign or reassign tasks, they can only assign the task to agency staff associated with security roles that are assigned to the swimlane in the underlying workflow process definition.The swimlane that contains the Start event node needs to be mapped to the PSCR Submitter Group. The procedure below uses that scenario as an example to illustrate the process used to map a security role to a swimlane.

To map swimlanes to roles:

1. Access the My Tasks area of Oracle Autonomous Integration Cloud.

2. Click My Tasks in the left navigation menu, and click Workspace in the My Tasks header.

3. Click Administration in the left navigation menu.

4. If the Manage Roles page does not appear by default, click Manage Roles in the left navigation menu.

   The Manage Roles page lists process roles using the format [application].[swimlane].

5. Search for your application to filter the list.

   The Process Owner and Process Reviewer roles are part of all applications. Other swimlanes in the list are ones that you created in your process definitions.

6. Add the delivered role PSCR Submitter Group to the swimlane that contains the Start event for your process model:

   1. Select the swimlane that contains the Start task in your process definitions.

      In the delivered Solution Packages that Oracle provides, this swimlane is labeled Applicant. This swimlane applies to the user submitting a transaction, such as a permit application.

   2. In the Assign Roles list for the selected swimlane, click Add Member.

   3. In the dialog box for adding members, search by Groups for PSCR Submitter Group.

      A group in OIC is equivalent to a role in the Public Sector Compliance and Regulation system.

   4. In the search results, select PSCR Submitter Group and then click OK to assign the role to the swimlane and return to the list of swimlanes.

7. Click Save.