Process Automation Overview

This topic provides an overview of how Oracle Permitting and Licensing uses OCI Process Automation and provides links to the OCI Process Automation documentation that is particularly useful for an Oracle Permitting and Licensing implementation.

Oracle Permitting and Licensing uses OCI Process Automation for designing and processing:

Workflow
Fee calculations

You use the Processes module to define:

Structured processes for Permits, Planning and Zoning, and Business Licenses workflow.
Dynamic process for Code Enforcement workflow.
Decision models to calculate fees for your transactions.

OCI Process Automation Documentation and Training

Before you begin implementing workflow and fees using OCI Process Automation, it is imperative that you become familiar with the OCI Process Automation features. The documentation in the Oracle Permitting and Licensing guides assume a general knowledge of OCI Process Automation and focus primarily on topics specific to the implementation and doesn't seek to duplicate information covered in OCI Process Automation documentation or training.

For more information on the OCI Process Automation, see Oracle Cloud Infrastructure Process Automation.

The link above provides access to valuable information such as:

Guides
Recipes (cookbook examples)
Training

While all of the information available for OCI Process Automation provide by the Oracle Cloud team is useful, in particular these topics are very valuable to help orient you as you being your implementation.

Topic	Description
Overview of Oracle Cloud Infrastructure Process Automation	Provides introductory information about the workspace, runtime, and use cases.
Applications at a Glance	Describes how to use the interface for setting up process applications, decision models, and roles.
Design Structured Processes	Explains how to create and work with structured workflow processes, which are used by Permits, Planning and Zoning, and Business Licenses.
Design Dynamic Processes	Explains how to create and work with dynamic workflow processes, which are used by Code Enforcement.
Model Decisions	Explains how to create and work with decision models for fee calculations.

OCI Process Automation Transition

Beginning with Release 24B, new customers will begin using OCI Process Automation. Existing customers will continue to use OIC Generation 2 for workflow and fees. At a later date, existing customers will receive notification on when they will switch from OIC Generation 2 to OCI Process Automation. For documentation purposes, existing customers should refer to the Release 24A version of the documentation for any OIC Generation 2 information.

Because the transition from OIC to OCI Process Automation can generate questions, a My Oracle Support page has been created to provide new information as it arises.

You can find updated information regarding this transition on My Oracle Support Document ID: 3005969.1, Oracle Integration Cloud (OIC) Generation 2 to Generation 3.

Migrating Workflow and Fee Models from Oracle Integration Cloud to Oracle Process Automation

As stated in the previous section, Oracle Permitting and Licensing is currently transitioning from Generation 2 to Generation 3 in terms of Oracle Process Automation, used for workflow and fee processing. Customers undergoing this change will need to migrate their fee and process definitions from Generation 2 to Generation 3. There is a set of Enterprise Scheduler Service (ESS) jobs provided to address migration tasks.

Access the migration ESS jobs by selecting Common > Migrate Workflow and DMN Models or entering Migrate Workflow and DMN Models into the Page Finder.

Use the Migrate Public Sector Workflow and Fee Decision Models Job page to run the jobs (actions) related to the Generation 2 to Generation 3 migration. Select the jobs from the Actions list.

Job	Description
Migrate	Run only on the Test pod. The migrate job: Migrates all workflow process and fee (DMN) definitions associated with a transaction type (permit, business license, planning and zoning, code enforcement case, and so on) from Generation 2 on Oracle Integration Cloud to Generation 3 on OCI Process Automation. Stores internal backups of each definition in case a rollback is required. Operates on a 100% success criterion. All definitions need to be migrated completely before the migration can be completed. In the event of an error, you must return to the Oracle Integration Cloud Generation 2 definition and fix any issues. Assigns members (users/groups) to the roles and sets the privilege level to Manage on the roles as needed. Sets the connector credential to the global OAuth credential. Note: If there are validation issues in the migrated workflow processes or fee models, you need to fix the issues in OCI Process Automation Generation 3 and activate the definitions manually. Proceed to the next action of publishing only after verifying validation issues in all migrated definitions are fixed and the definitions have all been activated successfully.
Publish workflow configurations	Run only on the Test pod and only after the Migrate job ran to 100% success. Publishes the newly migrated workflow and fee definitions onto the Oracle Permitting and Licensing transaction type tables, completing the migration process and enabling you to begin using OCI Process Automation Generation 3. After you run the Publish action, you must manually enable the Functional Setup Manager option for Workflow and DMN Source to OCI Process Automation. With this option enabled,you are confirming that the definitions were successfully migrated and published and that you intend to use OCI Process Automation Generation 3 for workflow and fees going forward. After completing this action: The currently in-process transactions for previously submitted applications will continue to use Oracle Integration Cloud Generation 2 for workflow and fees. Transactions for newly submitted applications will use OCI Process Automation Generation 3 for workflow and fees.
Rollback workflow configurations	This job can be run on the Test pod, Development pod, or Production pod. Rollback undoes the migration and publishing of the migrated workflow definitions on OCI Process Automation Generation 3 and resets the system to reference Oracle Integration Cloud Generation 2 settings and definitions. Caution: The rollback action should be used with utmost caution. It is highly recommended to contact an Oracle Support representative to determine if there is a way forward using OCI Process Automation Generation 3. Rolling back to Oracle Integration Cloud Generation 2 for worflow and fees involves performing several manual steps to reconfigure the system. Note: If you decide to rollback to Oracle Integration Cloud Generation 2 for workflow and fees, then after the Rollback action is run, you need to set the Functional Setup Manager option for Workflow and DMN Source manually to Oracle Integration Cloud. By running the Rollback action, you are confirming that you will move forward with Oracle Integration Cloud Generation 2 for workflow and fees.
Purge migration data	Run only on the Test pod. Run in the event of a Generation 2 process definition not being able to be migrated to Generation 3. This enables you to halt the migration activity by setting the migration status to Inactive for all entries in migration activity table and then re-run the Migrate action after issues with the Generation 2 definitions have been resolved and they ready for migration. Note: After running purge, make sure to delete all workflow and fee model definitions from the OCI Process Automation Generation 3 instance. When you re-run the Migrate action, the migration activity will begin fresh.

Migrating Automated In-Flight Generation 2 to Generation 3 Migration with Parallel Gateway

Agencies must migrate in‑flight Generation 2 workflow transactions to Generation 3 using a scheduled, time‑boxed job. With the parallel gateway enhancement, the migration can automatically move Generation 3 instances to the correct point in the workflow even when the current Generation 2 task is inside gateways, avoiding the manual step of mapping gateway IDs or tasks.

Before running Generation 2 to Generation 3 in‑flight migration, ensure the target Generation 3 workflow definition version is available and activated, and that the Generation 2 source and Generation 3 target definitions are aligned for migration. In particular, the human task list order values must match between source-to-target definitions and gateway node labels.

Note:

Parallel gateway start or end naming mismatches commonly cause alter‑workflow failures.

Let's take a look at the steps for migrating Generation 2 in-flight workflow applications to Generation 3:

Run the provided SQL to list the eligible Generation 2 in‑flight applications by record type, process definition, and version.
Call the REST API to insert a migration schedule row.
Run the Migrate Public Sector Active Applications Workflow Job process, and set the duration parameter to time‑box execution.
Verify schedule status outputs through the REST endpoints, because Generation 2 to Generation 3 migration doesn't include a full user interface by design.

Note:

For large backlogs, run the time‑boxed migration job after hours on a recurring schedule and always confirm results via schedule status. The job may complete successfully even when some migrations fail.

After the job completes, verify that a corresponding Generation 3 instance was created for each migrated application and that the workflow is positioned at the correct in‑progress task, with placement within parallel gateway branches. Confirm that task ownership and state (assignment, claim, reassign) carry over as expected, and that comments and attachments appear on the correct corresponding tasks in Generation 3.