4Developing Workflow Processes

Developing Workflow Processes

This chapter describes how to develop a workflow process. It includes the following topics:

• Roadmap for Developing Workflow Processes

• Process of Analyzing Business Requirements

• Process of Planning Workflow Processes

• Job Roles That You Use to Develop a Workflow Process

Roadmap for Developing Workflow Processes

To develop a workflow process, perform the following processes:

1. Process of Analyzing Business Requirements

2. Process of Planning Workflow Processes

3. Preparing Siebel Tools to Develop a Workflow Process

4. Creating the Workflow Process Object Definition

5. Diagramming a Workflow Process

6. Process of Testing a Workflow

7. Process of Deploying a Workflow Process

8. Process of Migrating a Workflow Process

9. Process of Administering a Workflow Process

Process of Analyzing Business Requirements

This process is a step in Roadmap for Developing Workflow Processes.

To analyze business requirements, do the following tasks:

1. Gathering Information for Planning a Workflow Process

2. Identifying Actions That the Business Process Performs

3. Identifying an Automation Solution

The first step in developing a workflow process includes analyzing your business requirements. You determine the rules and business processes that the workflow process must automate. An implementation project team typically spends a significant amount of time performing requirements analysis, with this step requiring as much as 30% of the total implementation effort. To define the processes to automate, a business analyst uses a Siebel CRM application, and then determines the most appropriate automation solution. The developer who defines the workflow process often participates as a technical consultant during this analysis.

Gathering Information for Planning a Workflow Process

This task is a step in Process of Analyzing Business Requirements.

You can gather information for workflow process planning.

To gather information for planning a workflow process

1. Determine how your organization currently handles business processes.

   For more information, see Analyzing Existing Performance of a Business Process.

2. Determine how the business process must perform in the future.

   For more information, see Identifying Areas for Improvement.

Analyzing Existing Performance of a Business Process

Current business processes provide the basis of what you define when you use Siebel Workflow. If you currently use an automated system, then you must gather information about the business processes that this system handles. It is also important to understand the limitations or problems of the current system that the workflow process must solve.

To analyze existing performance of a business process

• Research the following areas for your current business process:

  • Existing process information

  • Measures for improvement or new process requirements

The following sources might include existing process information:

• Current business processes that are automated

• Management guidelines

• Written guidelines for business process rules or approval paths

• Written or unwritten internal procedures

For example, assume you must document the lifecycle for a new work item, such as a service request, from the moment that someone opens the service request to the moment someone closes it. You can include information about the decision points in the business process. For example, if someone must escalate a service request or to describe the approval path that Siebel CRM must run if the service request is high priority compared to low priority.

Identifying Areas for Improvement

After you gather the required information about existing business processes, review it to determine if improvement opportunities exist or if a new business process is required.

To identifying areas for improvement

• Consider each of the following areas for improvement:

  • New management guidelines or business requirements that must be considered

  • Current problems that must be solved

  • Areas you must make more visible

  • Customer satisfaction issues

  • Workflow processes you must automate

Identifying Actions That the Business Process Performs

This task is a step in Process of Analyzing Business Requirements.

A business process includes actions that your organization must perform to meet business requirements. Siebel CRM provides a number of predefined actions. The following are some example predefined actions:

• Notifications. Send an email, page, or fax.

• Siebel Operations. Insert or update information in the Siebel database.

• Integration Messages. Request to send or receive data from an external system.

• Assignment. Use Assignment Manager to assign an object to someone.

• Navigation. Navigate a user to a specific view through a user interact step or a call.

• Server Request. Use the Siebel Server Request Broker to run a server process.

Siebel CRM calls a business service method to start each of these actions. This situation is true except for a Siebel operation. You can use these actions in a variety of settings and technical configurations. For example, you might identify a specialized action that calls a workflow process, such as calculate credit risk. You can define a custom business service to use a specialized action. A workflow process can call a predefined business service or a custom business service. For more information, see Example Workflow Processes That Call a Business Service and Integration Platform Technologies: Siebel Enterprise Application Integration.

To identify actions a business process performs

• Map the requirements you identified in Gathering Information for Planning a Workflow Process to potential predefined Siebel actions.

Identifying an Automation Solution

This task is a step in Process of Analyzing Business Requirements.

After you determine business process requirements and the actions that must be performed to meet those requirements, you can identify an automation solution.

To identify an automation solution

1. Identify the solution that most closely meets the business process requirements.

   For more information, see Identifying the Solution That Most Closely Meets the Requirements.

2. Determine if a workflow process or a workflow policy can meet the requirement.

   For more information, see Determining if a Workflow Process or Workflow Policy Meets the Requirement.

Identifying the Solution That Most Closely Meets the Requirements

Solution	Advantages	Limitations
Workflow Process	This solution includes the following advantages: Visual representation of business logic is simple to understand and maintain Remote synchronous and asynchronous capability provides compatibility across Siebel CRM for scalability and long-running transactions	This solution includes the following limitations: The semantics for control are not as rich as with scripting Limited control of flow for iteration through record sets Limited direct access to object methods
Workflow Policy	This solution includes the following advantages: Replies to a database event regardless of whether or not an Object Manager server component starts the policy Can realize higher transaction throughput for a simple transaction	This solution includes the following limitations: Policy changes might require database downtime More difficult to define than other alternatives Provides only a limited range of actions
Siebel Script	This solution includes the following advantages: Familiar to many developers Provides a set of semantics Is flexible	This solution includes the following limitations: More difficult to maintain and upgrade Slower performance

Determining if a Workflow Process or Workflow Policy Meets the Requirement

Requirement	Possible Solution
Capture business layer logic.	Use a workflow process. Workflow Process Manager and run-time events capture business layer logic.
Use features that a workflow process supports but that workflow policy does not support.	Use a workflow process. A workflow process can provide pause, stop, and error handling capabilities.
Implement complex comparison logic or flow management.	Use a workflow process. A workflow process is recommended to develop and deploy, and to perform complex comparison logic and flow management. For example, through IF, THEN, ELSE, or CASE.
Call a business service.	Use a workflow process. A workflow process can call a business service.
Use a repeating component request.	Use a workflow process. You can set up a workflow process from a repeating server component request but not from a workflow policy.
Repetitive, manual processing.	Use a workflow process. A workflow process is recommended for repetition, timeliness, and for cross functional routing through a business process.
Process an event in a timely fashion.
Perform escalations and notifications.
Capture data layer logic.	Use a workflow policy. Workflow Policy Manager captures data layer logic. Data coming into Siebel CRM in the data layer is not captured in the business layer. This requirement typically indicates a potential candidate for a workflow policy. Example data coming into Siebel CRM in the data layer includes data coming through EIM or MQ channels.
Use features that a workflow policy supports but that a workflow process does not support.	Use a workflow policy. A workflow policy can support some features that are not available or that are difficult to support with a workflow process. For example, email consolidation, duration, and quantity.
Do bulk data uploads.	Use a workflow policy. Workflow Policy Manager is recommended if bulk data upload occurs through EIM.
Do data quality cleaning in the data layer.	Use a workflow policy. Workflow Policy Manager is recommended for working in the data layer.

Process of Planning Workflow Processes

This process is a step in Roadmap for Developing Workflow Processes.

To plan a workflow process, do the following tasks:

1. Determining the Workflow Process Mode

2. Determining How to Start a Workflow Process

3. Determining the Decision Logic That the Workflow Process Uses

4. Determining the Actions the Workflow Process Must Perform

5. Determining Error Handling

6. Examining Seed Workflow Processes

7. Determining How to Manage Objects You Modify

8. Considering Other Business Requirements

If your work in Process of Analyzing Business Requirements determined that the workflow process is the most appropriate solution, then you can continue planning the workflow process. When planning a workflow process you determine how to build the workflow process, including making design decisions, such as which workflow mode to use, the events to define, the rules to define, actions that the workflow process runs, and so on.

Determining the Workflow Process Mode

This task is a step in Process of Planning Workflow Processes.

The Workflow Mode property of the workflow process determines if a workflow process can persist for a few moments, such as aiding a user with creating an email, or if it can span days and job functions, such as creating a quote to cash.

To determine the workflow process mode

• Map the business requirements to the most appropriate workflow mode.

  For more information, see Setting the Workflow Mode Property.

Determining How to Start a Workflow Process

This task is a step in Process of Planning Workflow Processes.

During the planning phase of a development effort you can determine if a run-time event, user event, workflow policy, or a script starts the workflow process. For more information, see Starting a Workflow Process.

To determine how to start the workflow process

• Consider the advantages and limitations of each configuration that can start a workflow process that this topic describes, and then choose the configuration that most closely matches the business requirements.

Using a Workflow Policy to Start the Workflow Process

A workflow policy starts a workflow process after a database change. If the workflow policy conditions are met, then an action occurs. In some situations, the action calls the Workflow Process Manager server component to run a workflow process. Processing that a workflow policy starts does not occur in real time. The following are typical uses of a workflow policy:

• EIM batch processing

• Siebel EAI inserts and updates

• Manual changes from the user interface

• Assignment Manager assignments

• Siebel Remote synchronization

Using an Event to Start the Workflow Process

You can use the following events to start a workflow process:

• Run-time event. A run-time event occurs if a change occurs in the client or in the business component. Processing that a run-time event starts occurs in real time.

• User event. A user event is a unique event that is internal to Siebel Workflow. It starts or resumes a long-running workflow process. The User Event business service creates a user event.

You can define an event from the administrative interface for one of the following object types:

• Application

• Applet

• Business Component

Using a Script to Start the Workflow Process

A script can start a workflow process programmatically as a business service. The Workflow Process Manager server component includes APIs that you can use with a script to start a workflow process from an external system. The Object Manager starts a script. You can add a script to one the following object types:

• Application

• Applet

• Business Component

• Business Service

Summary of Configurations That Start the Workflow Process

Configuration	Description	Limitations
Workflow Policy	Use a workflow policy if Siebel CRM must detect and react to data changes that occur outside of the Object Manager. For example, changes that occur in Siebel Remote or Siebel EIM.	A workflow policy includes the following limitations: Making changes requires database downtime Relatively complex to define
Event	Use an event in the following situations: You must configure a basic entry point for a workflow process or a simple custom action.	An event includes the following limitations: You cannot write script on the object event to reply directly to an event. Can be more difficult to send the event context to business logic. Only detects data changes that the Object Manager component makes.
Script	Use a script in the following situations: You must write a script directly in reply to an event. Siebel CRM must access an applet event that only Siebel Tools displays.	A script includes the following limitations: Only detects data changes that the Object Manager component makes. You must write the script on an object event.

Determining the Decision Logic That the Workflow Process Uses

This task is a step in Process of Planning Workflow Processes.

You can determine the decision logic that guides the flow of control in a workflow process. For more information, see Configuring a Decision Condition for a Workflow Process.

To determine the decision logic that the workflow process uses

1. To determine if the business process requires decision conditions, examine the business analysis work you have completed.

   For more information, see Objects That Siebel Workflow Uses.

2. Map the requirements to the workflow process decision logic.

   For more information, see Configurations That Use Decision Logic in a Workflow Process.

Configurations That Use Decision Logic in a Workflow Process

Configuration	Description	Limitations
Decision point in workflow process	A workflow process step that determines the flow between alternative branches in the workflow process. Use a decision point in workflow process if you require a simple decision that uses one or more alternative branches in a workflow process. Each connector that emanates from a decision point can contain one or more decision conditions. If the conditions evaluate to TRUE for the connector, then flow proceeds down the branch that the connector represents.	A conditional expression does not support the following operators: AND OR Order of precedence, as determined by parentheses in an equation
Scripted Business Service	A script in a business service action step that evaluates a potentially complex set of inputs and returns a simplified output that a decision point can evaluate. Use a scripted business service if a decision point cannot meet the decision logic that your business requires.	Reduces readability and increases complexity because decision logic resides a script.
Wait Step	Allows you to pause a workflow process for an amount of time or until an event occurs. Use a wait step if you must support an escalation that depends on time or a long-running workflow process that can last for days or weeks. For example, waiting for a customer reply.	The Object Manager must call the releasing event.
Other Specialized Decision Frameworks	A workflow process can directly or indirectly use other decision frameworks. For example, personalization rules, assignment rules, or EAI Dispatch Service. Use other specialized decision frameworks if a specialized decision framework is required. For example, if Siebel CRM must assign work to a person according to the expertise that this person possesses.	Limitations vary depending on the decision framework.

Using Decision Conditions with the Decision Point

You can use a decision condition to determine the flow that Siebel CRM must take on a branch in a workflow process. A decision point can exist with multiple connectors where each connector represents a logical branch. Siebel CRM can evaluate a decision condition for each connector that provides branching. A decision condition can make a comparison between two of the following items:

• Process properties

• Business component fields

• Literal values

A comparison can include the following terms:

• Two values that are equivalent.

• One value exists among a series of other values. For example, child record values, One Must Match, or All Must Match.

• Greater than (>) or less than (<).

• Between or Not Between.

• Null or Not Null.

For an example that uses the Compose Condition Criteria dialog box, see Defining a Decision Condition for the Decision Point. For a description of properties that the Compose Condition Criteria dialog box displays, see Creating a Decision Condition on a Branch Connector.

Determining the Actions the Workflow Process Must Perform

This task is a step in Process of Planning Workflow Processes.

You can determine the actions that the workflow process must perform.

To determine the actions the workflow process must perform

• Identify the type of actions that the workflow process must perform to meet the business requirements.

  For more information, see Objects That Siebel Workflow Uses, and Data Manipulation in a Workflow Process.

Data Manipulation in a Workflow Process

A workflow process operates on business objects and business components. It references a single business object. In the context of these data layer objects, Siebel CRM creates or updates data while the workflow process runs. A workflow process can modify the following data:

• Business component data

• Process property data

• Siebel Common Object data

Siebel Tools creates a set of predefined process properties when you create a workflow process. You can think of a process property as a local variable that is active while a workflow process instance runs. Siebel CRM can use the process property as input and output to various steps in a workflow process. The Process Instance Id is one example of a predefined process property. For more information, see Using Process Properties.

Uses and Limitations of Actions That the Workflow Process Performs

Action	Description	Limitations
Business service Step	Use a business service step if you must run a potentially complex and reusable set of logic. A workflow process step that calls a business service method. The business service can be predefined or scripted.	Creating and deleting business services can impact system performance. Caching can reduce overhead. Incorporating too much logic in a business service can limit reusability for the business service and can reduce the transparency of the workflow process.
Siebel operation Step	Use a Siebel operation step if you must run simple record operations in the workflow process. A workflow process step that does inserts, updates, and queries on business component data.	A search specification can update multiple records but it cannot get and iterate through a set of records so that subsequent actions for the workflow process can run for each record.

Using the Business Service Step

A business service step can run a predefined or a custom business service method. The following items are examples of predefined business services:

• Assignment Manager requests

• Notification through the Communications Server

• Server requests

• Integration requests from Siebel EAI

You can write a custom business service in Siebel VB or Siebel eScript. If you add a business service step, then you must define the business service, the business service method, input arguments, and output arguments for that step. Siebel CRM passes input arguments in a process property, business component data, or as a literal value.

The following list includes some business services that a workflow process typically uses:

• Outbound Communications Manager

• Synchronous Assignment Manager Requests

• Server Requests

• Report Business Service

• Audit Trail Engine

• EAI business services, such as EAI Siebel Adapter, EAI XML Converter, and so on

• FINS Data Transfer Utilities and Data Validation Manager

For more information, see Adding a Business Service Step, and Predefined Business Services.

If you require specialized functionality, then you can define a custom business service that performs a specific action. You can define a business service in Siebel Tools or in the administration screens of the Siebel client. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.

Using the Siebel Operation Step

The Siebel operation step allows you to configure Siebel CRM to do database operations. For example:

• Query

• Insert

• Delete

• Update

• NextRecord

• Upsert

• PreviousRecord

• QueryBiDirectional

A Siebel operation step references a single business component. After you define a Siebel operation step, you can use the Search Specification property to locate the records that Siebel CRM must use or modify. Examples of a Siebel operation step include creating an activity if the user creates a new service request, or updating a comment field if a service request is open too long. For more information, see Adding a Siebel Operation Step.

Determining Error Handling

This task is a step in Process of Planning Workflow Processes.

The planning phase is an appropriate time to plan for how to recover from a failed workflow process. Error handling can range from using a simple stop step to defining a separate workflow process that handles the error. For more information, see Handling Errors.

To determine error handling

1. Determine what, if any, error handling is required to meet the business requirements.

2. Identify the error handling action that can meet the business requirements.

Examining Seed Workflow Processes

This task is a step in Process of Planning Workflow Processes.

A seed workflow process is a workflow process that comes predefined with Siebel CRM. Before you create a new workflow process, you can determine if a seed workflow process already exists that meets your business requirements.

To examine seed workflow processes

1. In Siebel Tools, in the Object Explorer, click Workflow Process.

   For more information, see Locating a Workflow Process in the Workflow Processes List.

2. Scroll through the Workflow Processes list, scanning the Process Name property for a potential candidate.

3. Seed workflow processes include all the workflow processes that Siebel Tools displays in the Workflow Processes list immediately after you install Siebel Tools but before you define any new workflow processes.

4. Use the Process Designer in Siebel Tools to further examine potential candidates that you identify in step 2.

5. To determine if it is appropriate to use a copy of a seed workflow process, consider how much you must modify this workflow process to meet the business requirements.

6. If you identify a candidate workflow process, then make a copy of it and modify the copy.

   Siebel CRM uses some seed workflow processes to run some of the basic functionality of a Siebel CRM application. You must not edit a seed workflow process. Instead, create a copy of it, and then edit the copy. For more information, see Copying a Workflow Process.

Determining How to Manage Objects You Modify

This task is a step in Process of Planning Workflow Processes.

When you plan a workflow process, you can determine the requirements that are necessary to manage the development of objects, such as special requirements that exist for merging, archiving, and importing data maps, or for copying message tables. If a team of developers is involved in the development environment, then you must consider if the team can use project check in and check out.

To determine how to manage objects you modify

1. Consider the number of developers that are involved in the project and the requirements of their development environments.

2. Choose a tool that you can use to manage objects.

   For more information, see Object Management Tools That You Can Use in Siebel Tools.

Object Management Tools That You Can Use in Siebel Tools

When you develop a workflow process in Siebel Tools, you work on a local database where Siebel Workflow is a repository object and where a workflow process belongs to a project. For more information, see Process of Deploying a Workflow Process.

Although Siebel CRM typically uses the following behaviors for other repository objects, a workflow process does not use them:

• Merge. A workflow process does not participate in three way merge. If you import a workflow process to the repository, then Siebel Workflow maintains versioning for the workflow process.

• Object Comparison. Siebel CRM disabled object comparison starting with Siebel CRM version 8.0.

• Archive.

To develop a workflow process, a developer usually uses a local database. To use a local database, the developer must check out the workflow process from the master repository. The local database must contain the data objects that the workflow process references. The developer must import into the local database any data objects that are not docked and that are not packaged as part of the database extract. Siebel Workflow does not dock or reference the following objects:

• Data maps. To import a data map to the local database, you use the Siebel Developer Web Client connected to the local database and the import utility on the client.

• Message tables. You can copy a message table to the local database. Alternatively, you can use the unbounded drop-down list to define a message. While this tool allows you to create messages, it does not verify message validity when you define it.

If you lock the project in the master repository, and if you connect Siebel Tools to the development database, then you can develop or modify a workflow process. It is not necessary for you to make lists of values available to the local database.

Considering Other Business Requirements

This task is a step in Process of Planning Workflow Processes.

To determine if you must consider other business requirements, consider your development and implementation environment.

To consider other business requirements

• Consider some of the other business requirements:

  1. Use the Workflow Process Batch Manager to run a workflow process on the records in a business component at a predetermined interval.

     For more information, see Configuring Batch Processing.

  2. If you implement the workflow process in a multilingual environment, then configure it for globalization.

     For more information, see Configuring a Workflow Process for a Multilingual Environment.

Job Roles That You Use to Develop a Workflow Process

This topic describes job roles that you can use to develop a workflow process. Job roles, job titles, and division of labor might vary significantly for your organization. The following job roles are associated with developing a workflow process:

• The business analyst considers business requirements for your organization and identifies the business processes to automate.

• The workflow configurator uses Siebel Tools to create a workflow process and to define objects, business services, and programs. Your organization can use the objects, business services, or programs that come predefined with Siebel CRM. The workflow configurator can also define custom objects, business services, and programs in Siebel Tools. This configurator can define a business service in the Siebel client. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.

• The workflow administrator uses Siebel Workflow to monitor a workflow process in the Siebel client. To activate a workflow policy, the workflow administrator creates database triggers in a script and defines them in the Siebel database. The workflow administrator then starts the Siebel Server processes that run the workflow process and workflow policy. This person is typically a system administrator, database administrator, or someone from the Information Services department.

• The user uses the Siebel client and causes the workflow process or workflow policy to run. This person is typically an employee of your organization, and can also be a customer.