1Setting Up Workflow

Workflow Basics

You define your permit 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 permit workflow. The list of steps includes links to additional permit-specific information. Use this permit-specific documentation in conjunction with the OIC documentation to learn how to set up workflow.

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

Note: Oracle provides a Solution Package with sample workflow configurations for permits. 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.

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 permit 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 permits.
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 permit type until you activate a version of the application that includes your changes. 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 permit types that need to use the new version.
Process Definition	A process definition is a specific workflow process. When different permit 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 permit 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 notes about permit-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 permit workflow.

3. Set up your permit-specific integrations.

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

4. Create the process definition.

   Note: For permit 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 permits. See Setting Up Process Definitions for Permit Workflow for these important permit-specific tasks:

   • Setting Up Permit 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 Permit Status Updates

   • Defining Data Associations for Retrieving Permit Base Data

   • Defining Data Associations for Retrieving Permit Field Data

   • Defining Data Associations for Retrieving Permit Type Data

   • Defining Statuses (Outcomes) for Human Tasks

   • Defining Conditional Logic for Gateways

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

   See Using Custom Properties in Permit Workflow.

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 permit 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 permit types so that they reference the new version number.

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.

Reviewing a Sample Process Definition

A process definition provides a defined flow for processes such as the permit lifecycle. 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.

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, you create a custom role, then you create a user manually and assign your custom role to that user. You use the Security Console to complete this task. For more information about using the Security Console, refer to your Oracle Identity Cloud Service documentation at https://docs.oracle.com/en/cloud/paas/identity-cloud/

Caution: The role you create in this step should not be assigned to any user other than the OIC proxy user.

To create the OIC proxy user role:

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. On the Roles tab of the Security Console, click Create Role.

3. On the Create Role: Basic Information page, enter PSCR Proxy User for OIC. in the Role Name field.

4. In the Role Code field enter CUSTOM_PSCR_OIC_PROXY_USER.

5. In the Role Category field, select Financials - Job Roles.

6. In the Description field, enter This role should NOT be assigned to any user other than the OIC Proxy User.

7. Click Next until you reach the Role Hierarchy page, and add these roles as child roles:

   • ORA_PSC_UPDATE_PERMIT_STATUS_ALL_AGG

   • CUSTOM_PSC_MANAGE_PERMITS

   • CUSTOM_PSC_MANAGE_PERMITS_AGENCY

8. Click Next until you reach the Summary page.

9. Click Save and Close.

To create the OIC proxy user:

1. Click the Users tab.

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

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

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

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

6. 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 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, but this procedure explains 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.

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 Permit 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 permit 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 for the communications integration.
   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 permit 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 permit 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 Permits Connector

The permits connector enables OIC to exchange permit-related information with the Public Sector 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, but the procedures in this topic explain how to set up the permits connector from scratch.

The procedures that follow are for entering the specific 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

The procedures related to setting up integration connectors require you to import code using files that you download from My Oracle Support (MOS) Doc ID 2449735.1, Public Sector Compliance and Regulation: JSON Files for Permit Integration. Each procedure includes a step for downloading specific files. It’s easier, however, if you download all of the files from the MOS document at once rather than returning to the MOS document multiple times.

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

Setting Up the Permits Connector

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

To set up the permits connector:

1. Access the main console in OIC.

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

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 PermitsConnector for the permits integration.
   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 when you activate the permit workflow application, you can skip the security-related steps in this procedure and skip ahead to step 13, where you begin setting up the outbound communications resource in this integration. 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

Adding the PATCH Operation for Permit Statuses

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

Permit workflow in OIC uses the PATCH operation to update the status of a permit.

To set up the PATCH operation:

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

   • RequestPermitStatusUpdate.json

   • ResponsePermitStatusUpdate.json

2. Access the main console in OIC.

3. In the list of OIC applications, click the application for your permit workflow.

4. Click the Integrations option in the left frame.

5. Click the PermitsConnector integration.

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

7. Expand the new Resource section that appears, and enter PermitResources in the Name field.

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

9. Click the new PATCH operation.

10. Enter the following information:

    Page Element	Value
    Name	patchPermitStatus
    Path	{permitResource}/{permitRecordKey} 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 permit status.

11. Click Request

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

13. Enter RequestPermitStatusUpdate in the Name field.

14. Click Schema.

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

16. Locate and upload the RequestPermitStatusUpdate.json file that you downloaded from My Oracle Support.

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

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

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

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

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

    These are example descriptions:

    Parameter	Description
    permitResource	Permit Resource Name
    permitRecordKey	Permit Record Key

20. Click Response.

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

22. Enter ResponsePermitStatusUpdate in the Name field.

23. Click Schema.

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

25. Locate and upload the ResponsePermitStatusUpdate.json file that you downloaded from My Oracle Support.

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

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

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

    Field	Value
    Body	BusinessData.ResponsePermitStatusUpdate
    Media Type	application/JSON

28. Click Apply.

29. Click Save.

Adding GET Operations for Permit Data

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

In this procedure, you will set up two GET operations for fetching permit data.

• GetPermitBaseData gets general permit data that is found in all permits, such as the permit type, the permit status, and the permit applicant.

• GetPermitFieldsData gets information from the permit application (the intake form whose fields are configured using the permit designer).

To set up the GET operations for permit data:

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

   • ResponsePermitBase.json

   • ResponsePermitFields.json

2. Access the main console in OIC.

3. In the list of OIC applications, click the application for your permit workflow.

4. Click the Integrations option in the left frame.

5. Click the PermitsConnector integration.

6. Expand the PermitResources resource.

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

8. Click the new GET operation.

9. Enter the following information:

   Field	Value
   Name	getPermitBaseData
   Path	{permitResource}/{permitRecordKey} 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 permit data, such as applicant information

10. Click Request

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

    These are example descriptions:

    Parameter	Description
    permitResource	Permit Resource Name
    permitRecordKey	Permit Record Key

12. Click Response.

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

14. Enter ResponsePermitBase in the Name field.

15. Click Schema.

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

17. Locate and upload the ResponsePermitBase.json file that you downloaded from My Oracle Support.

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

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

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

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

20. Click Apply.

    This completes creation of the GetPermitBaseData operation.

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

22. Click the new GET operation.

    The new GET operation has the default name is GetPermitResources

23. Enter the following information:

    Field	Value
    Name	getPermitFieldsData
    Path	{permitResource}/{permitRecordKey}/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 permit data, such as job cost

24. Click Request.

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

    These are example descriptions:

    Parameter	Description
    permitResource	Permit Resource Name
    permitRecordKey	Permit Record Key

26. Click Response.

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

28. Enter ResponsePermitFields in the Name field.

29. Click Schema.

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

31. Locate and upload the ResponsePermitFields.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 GET operation response:

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

34. Click Apply.

35. Click Save.

Adding a GET Operation for Permit Type Data

Note: Before starting this procedure, be sure to complete the procedure “Adding GET Operations for Permit Data.”

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

To set up the GET operations for permit type data:

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

2. Access the main console in OIC.

3. In the list of OIC applications, click the application for your permit workflow.

4. Click the Integrations option in the left frame.

5. Click the PermitsConnector integration.

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

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

   Field	Value
   Name	PermitTypeResource
   Path	publicSectorRecordTypes

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

9. Click the new GET operation.

10. Enter the following information:

    Page Element	Value
    Name	getPermitTypeData
    Path	{permitResource}
    Documentation	Get permit type setup data

11. Click Request

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

    Here is an example description:

    Parameter	Description
    permitResource	Permit Resource Name

13. Click Response.

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

15. Enter ResponsePermitType in the Name field.

16. Click Schema.

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

18. Locate and upload the ResponsePermitType.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 GET operation response:

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

21. Click Apply.

22. Click Save.

Setting Up Process Definitions for Permit Workflow

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

Note: The procedures in this topic relate to the specific requirements of permit workflow. To create your permit 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

Setting Up Permit Data Definitions for a Process

Data definitions provide a structure for storing data from the permit system. Every process definition that you create needs the same data definitions, including:

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

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

  The data definition for permit fields includes all possible fields on the permit intake form, even though permits use only the subset of fields that are appropriate for the type of permit. Any fields that are not part of a specific permit remain blank when the workflow process retrieves the permit field data.

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

Note: Before you set up your data definitions, you need to set up the permit connector for the application. This is because the permit connector’s three GET operations have the schema for the data. Setting up the permit connector is described in the topic Setting Up the Permits Connector.

To set up data definitions in a process definition:

1. Access the process definition in OIC.

2. Click Data Objects.

3. Set up the data definition for permit 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	permitBaseData
      Data Type	Business
      The drop-down list for data types	BusinessData.ResponsePermitBase

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

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

   1. Click Add.

   2. Enter the following information:

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

   3. Click Create.

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

   1. Click Add.

   2. Enter the following information:

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

   3. Click Create.

6. Create simple string data objects for the permit fields that contain identifying information about permits and permit types:

   To create these strings:

   1. Click Add.

   2. Set up the string using the values in this table, where each row represents a separate data definition that you need to create:

      Name	Data Type	Drop-down list for the data type
      recordKey	Simple	String
      recordTypeKey	Simple	String
      ExternalBaseURL	Simple	String
      resourceName	Simple	String

   3. Click Create.

   4. Repeat for all additional rows in the table.

7. Click Close to close the Data Objects window.

8. Click Save.

Defining Arguments for the Start Event

When a permit instantiates its workflow process, it passes parameters such as the permit ID to the workflow system. The Start event must have arguments for these parameters.

To set up the arguments for the start event:

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

2. Open the event 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. Add the following rows to the Arguments Definition.

   Name	Type
   RecordKey	String
   RecordTypeKey	String
   ExternalBaseURL	String
   ResourceName	String

6. 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 permit..

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 input data associations.

   Source Data (Left side of the map)	Target Data (Right side of the map)	Description
   RecordKey	recordKey	The permit ID.
   RecordTypeKey	recordTypeKey	The permit type ID.
   ExternalBaseURL	url	The URL for the permits system.
   ResourceName	resourceName	The name of the REST API resource for permits.

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 five communication events, LNP_WORKFLOW_001 through LNP_WORKFLOW_005.
   [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 permit application.
   "LnpRecordKey"	body.recordFirstKeyName	The name of the key field for permits
   recordKey	body.recordFirstKeyValue	The permit 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 Permit Status Updates

The data associations for a permit status update task define the information that the task sends to the permit system.

To set up the data associations:

1. Access the process definition and select the system task that updates the permit 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
   resourceName	resourceName	The unique system identifier for the permit type.
   recordKey	recordKey	The permit ID
   [new permit status] For example: "Accepted"	body.status	The status to be assigned to the permit. The source data string must be in quotation marks, and it must exactly match one of the valid statuses in the permit application.

4. Click Apply.

5. Click Save.

Defining Data Associations for Retrieving Permit Base Data

The data associations for a task that retrieves permit 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 permit 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
   resourceName	permitResource	The unique system identifier for the permit type.
   recordKey	permitRecordKey	The permit 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	permitBaseData	This business object contains all of the permit base data. Mapping individual fields would be much more complex and is not necessary.

6. Click Apply.

7. Click Save.

Defining Data Associations for Retrieving Permit Field Data

The data associations for a task that retrieves permit 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 permit 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
   resourceName	permitResource	The unique system identifier for the permit type.
   recordKey	permitRecordKey	The permit 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	permitFieldsData	This business object contains all of the permit fields. This includes all fields that can be included on the permit intake form, whether or not the field exists for a specific permit. 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 permit data. Mapping individual fields would be much more complex and is not necessary.

6. Click Apply.

7. Click Save.

Defining Data Associations for Retrieving Permit Type Data

The data associations for a task that retrieves permit 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 permit 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
   resourceName	permitResource	The unique system identifier for the permit 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	permitTypeData	This business object contains all permit 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 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. Permit field data (the data from the intake form) is nested within the items element under PermitFieldsData.

   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.

Using Custom Properties in Permit Workflow

When you set up permit workflow, a variety of custom properties are available for implementing permit-specific functionality.

These custom properties are available for permit 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
PSC_FINAL_ACTIVITY	Use this property to identify a human task that is not allowed to progress when the permit 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 Permit.	Yes identifies the final activity. A blank value or a No value means that the task is not the final activity.
PSC_ACTIVITY_TYPE	Use this property to identify the final inspection task in the process. Setting this property is necessary to support the permit 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 permit business logic that auto-advances the inspection task when the last inspection is closed.	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.

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

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 can be associated with multiple roles. It can also be associated with one or more individual users.

The swimlane that contains the Start event needs to be mapped to the OIC proxy user role, or to the OIC proxy user that you created in the procedure Setting Up a Proxy Role and User for Oracle Integration Cloud. In the following instructions, you will map the swimlane to the role.

To map swimlanes to roles:

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

2. Click the Workspace button in the right frame.

3. Click Administration in the left frame.

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

   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 Proxy User for OIC to the swimlane with the Start event:

   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.

   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 Proxy User for OIC.

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

   4. In the search results, select PSCR Proxy User for OIC and then click OK to assign the role to the swimlane and return to the list of swimlanes.