2Setting Up Workflow for Code Enforcement

Code Enforcement Workflow Basics

This topic introduces you to the elements in a process definition used in Public Sector Compliance and Regulation's Code Enforcement offering.

Code Enforcement Workflow Overview

Adding workflow to Code Enforcement transactions enables you to automate the progression through the stages and activities and incident or case process flow. Public Sector Compliance and Regulation offerings use the Oracle Autonomous Integration Cloud (OIC) for designing workflow process definitions and running the workflow engine that drives transaction automation. Before you begin implementing workflow for Code Enforcement, it is imperative that you become familiar with the Processes feature in OIC.

For more information on the OIC Processes feature, see Using Processes in Oracle Integration.

How Code Enforcement implements workflow is a little different than the way other Public Sector Compliance and Regulation offerings do. Permits, Planning and Zoning and Business Licenses use a structured process design, which is suitable for more linear, sequential transaction flows. The Code Enforcement transaction flows can contain stages and activities that don't necessarily occur in a set order, and some may occur at the same time, while others may not occur at all.

Because of the non-sequential nature of a typical Code Enforcement transaction flow, you will create a dynamic process design. The dynamic process design is a departure from the standard "step 1, step 2, step 3" approach to process design. With a dynamic process definition, you define the stages and activities of the process flow, but you don't define any particular order. You define conditions that drive when or if a particular stage or activity becomes activated, providing the flexibility the Code Enforcement offering requires.

For more information on dynamic processes, see Develop Structured Processes.

Note: Oracle provides a Solution Package with sample workflow configurations. It is highly recommended that you clone these samples and use them as starting points to create your own workflow.

Important OIC Terms

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.

General Topics Related to Workflow

The topics in this chapter are specific to the Code Enforcement workflow implementation. However, the following workflow topics apply to all Public Sector Compliance and Regulation offerings. Make sure to be familiar with these topics and complete any setup tasks as needed.

• Setting Up a Proxy User for Oracle Integration Cloud

• Monitoring Workflow Transactions

Working with a Dynamic Process Definition

This topic provides an overview of the main elements in the dynamic process design used for the Code Enforcement offering and describes the top-level configurations you can make.

The sample process definitions provided in the solution package contains examples of all the elements that can be used for a Code Enforcement. The topics in this chapter go into more detail on each element and describe how to configure the element within the process, while pointing out what you should not change. With all of the elements, the power and flexibility they provide can be achieved by configuring the conditions that determine when they become active.

This example illustrates the main elements of a Code Enforcement dynamic workflow process. Details are in the surrounding text.

Process-Level Settings

In the process-level settings, which you can access in the header of the process definition should be used as delivered in the solution package samples.

The input data is mapped to the data stored in the business type. Click the Input Data button to display the Start the Dynamic Process window. The process for Code Enforcement should be started with the With Data Only option selected. The Interface Arguments reflect the data stored in the business type.

When editing the process-level settings, you can change:

• Name (which you create when cloning the sample)

• Description

• Roles

The Termination condition set at the process level enables the entire process instance to be stopped in the event that the case status is set to closed.

The roles that you include at the process level will be inherited and can be used in all of the elements within that process, such as stages or activities. At the stage and activity level, you can add more specific security settings (roles and users) as needed. You can create roles for the process and map them to existing PSC roles, such as PSC Code Enforcement Officer or to specific users if required.

Stages

Stages enable you to organize activities into phases of a process. Stages can run at the same time or one after another. Examples of stages in the Code Enforcement process definition include Violation, Citation, Appeal, and so on. Each stage represents a different phase of the workflow with its own set of activities.

See Setting Up Stages.

Activities

Activities represent actions or tasks that need to be completed within the process. Activities can be carried out by a human, or they can be automatically completed by calling another process or integration, such as a REST service.

See Setting Up Process Activities.

Milestones

Milestones represent a sub-goal within a process. Milestones are typically defined to track progress of a process.

See Setting Up Milestones.

Global Trigger Activity

The "global trigger activity" is an activity that appears in the process definition below the stages. It is used internally by the process to receive the incoming payload to instantiate the process instance. Updates in the transaction system flow through the global trigger activity, which in turn provide data for the conditions defined within the stages to advance the workflow. You can rename the global trigger activity and modify role assignments but otherwise you should not modify or remove it from the process definition.

Note: If you remove the global trigger activity, the workflow can't be instantiated.

See Setting Up Process Activities.

Setting Up Connectors for Code Enforcement

In this topic we describe the process definitions connectors, or integrations, that enable Code Enforcement and Oracle Integration Cloud (OIC) to share data.

To access the integrations for a process definition, select Integrations in the left panel of the user interface. The Case Data integration combines these REST resources to enable the exchange of information about Code Enforcement cases:

• Cases (publicSectorCases)

• Case Notices (publicSectorCaseNotices)

When migrating from environment to another, such as from the Test to Production migration, make sure to update the base URL for the integration to match the URL of the new environment.

Cases

Resource Element	Value
Name	Cases
Resource	publicSectorCases
Operations	GET (getCases)
Response	BusinessData.ResponseCaseData

Case Notices

Resource Element	Value
Name	CaseNotices
Resource	publicSectorCaseNotices
Operations	PATCH
Path	{noticeKey}
Request	CaseNotice.CaseNotice Parameters (noticeKey)
Response	CaseNoticeResponse.CaseNoticeResponse

Setting Up Data Storage

This topic describes how the process definition for Code Enforcement receives data and stores it for usage during the life cycle of the process instance.

Working with Forms

When the process instance gets instantiated, the Code Enforcement system sends the required data to OIC through a web form. The web form captures the data sent in the Code Enforcement payload.

Note: Do not remove any attributes from the web form, but you can add additional attributes if your use case requires additional attributes.

Access the web form by selecting the Forms tab in the left panel.

This example illustrates the Forms configuration user interface.

Working with Business Types

There is a one-to-one relationship between the form and the business type. The data collected through the form is then stored in the business type object. During the life cycle of the process instance, the stored data is used by the criteria you define to evaluate and carry out the workflow automation, such as activating various activities or stages when specific events occur or statuses have been set.

Note: Do not remove any attributes from the business type, but you can add additional attributes if your use case requires additional attributes.

This example illustrates the Business Type configuration user interface

Setting Up Stages

This topic describes how to set up stages to group process activities and milestones.

The following topics describe the settings you can use to modify stages. For more information on stage properties, see Define Stage Properties.

General Settings

You can update:

• Name

• Description

• Markers

Conditions

You can add additional events and conditions as needed. However, keep the initial events and conditions as is. The delivered events and conditions enable the expected activation and processing of the stages.

This example illustrates a delivered activation event and data driven condition. Details are in the surrounding text.

The event is based on the activation of the Global Activity, and the data driven condition is based on a specific status of an attribute in the business type. For example, for the Violation stage to activate, caseCurrentStatus must have been set to ORA_VIO.

This example illustrates the settings for the data driven activation condition. Details are in the surrounding text.

Roles

This example illustrates modifying roles at the stage level. Details are in the surrounding text.

On the Roles tab, notice the roles that are inherited from the top-level process definition in the Inherited from: <Process Name> box. Any roles you add appear below the inherited roles.

Page Element	Description
Name	Name of the role.
Members	Select PSC roles or specific users to associated with the dynamic process role. Enter partial values, such as PSC, to display the synchronized roles with the Code Enforcement system.
Permissions	Click Create Permission to add a new permission.
Name	Enter a permission name.
Items	Click in the field to display a list of items to which you can select to grant access, such as to various stages, activities, or to the entire process by selecting Process.
Actions	Select the access to enable for the item, such as Update, All, None, and so on.

The stages you define will appear at the top of the Workflow page when view case or incident details. For more information, see Using Workflow.

Setting Up Process Activities

This topic describes how to configure activities to reflect the human and system actions in the workflow process.

You can add as many activities as you need to meet your business requirements.

Note: Do not remove the global activity at the bottom of the workspace below the stages. It is required to instantiate the process instance. You can create additional global activities if required. Global activities do not display in the run-time user interface.

This example illustrates activities within stages above the global activity at the bottom of the workspace. Details are in the surrounding text.

You can configure the General settings, Conditions settings, and Roles settings similar to stages. For more information on activity settings, see Define Activity Properties, and for more information on stages see Setting Up Stages.

Note: If the first activity in a stage is a Service activity, you need to include a Process activity that calls a structured process defined with a 5 second interval (5s). In the examples, this activity is named Timer 5s. This creates a 5-second delay to ensure all initialization and activation processing has completed prior to starting the stage.

The activities defined for a stage appear on the Workflow tab when viewing case or incident details. For more information, see Using Workflow.

Setting Up Milestones

This topic describes how to include milestones within the stages of your process definition.

A milestone is a type of activity that represents a sub-goal within a process. Milestones are typically defined to track progress of a process. The process reaches a milestone when the status of an activity has been completed, for example.

This example illustrates a milestone. Details are in the surrounding text.

In this example, the milestone is reached when the Prepare Hearing activity has been completed.

At runtime, agency staff can view the workflow using the milestone view or the stage view. For more information, see Using Workflow.

Linking Process Definitions to Issue Subtypes

This topic describes how to prepare process definitions for use and how you reference them from your issue subtypes.

After you have defined your dynamic workflow process, you then need to publish and activate it so that it can be accessed and referenced by Code Enforcement. Then, you can reference it in the Code Enforcement setup pages to associate the definition with one or more issue subtypes.

Step	Link
Create a process definition group.	Setting Up Process Definition Groups
Reference the process definition group in the issue subtype.	Setting Up Issue Subtypes