Siebel Business Process Framework: Task UI Guide > Scenario for Developing a Task UI > Example of Developing a Task UI >

Designing the Task UI

This task is a step in Example of Developing a Task UI.

To design the task UI, the business analyst begins by modeling the business process.

Modeling the Business Process

With low risk and high ROI, the executives at the organization approve the proposed project. The business analyst is now ready to model the business process, and names the business process Expense Reimbursement. This name reflects the fact that the objective of the business process is not simply for employees to report expenses, but for the company to reimburse employees for the valid expenses they incur while conducting business for the organization.

The next step is to separate the business process into separate activities. The business analyst answers the question Who does what? The answer to this question identifies the following roles:

• Submitter
• Reviewer
• Payer

The business analyst also identifies the following activities that can occur in the business process:

• Submit expense report, accomplished through a task UI
• Review expense report, accomplished through a task UI
• Pay expense report, accomplished through a business service

A favorable candidate for a business service must work as an independent entity to make sure reusability is possible. It is recommended that you use comments to document this business service to support other developers who must use the code. It must also follow a standard naming convention to make it easier for others to view the structure and understand what is happening in the code.

A favorable candidate for a task UI supports the entire business process and guides the user in performing the user role in this business process. The task must be clearly structured to make it easy for others to follow and understand.

The business analyst makes the following observations:

• Submitting an expense report is difficult to automate, so the analyst identifies it as a candidate for task UI.
• Reviewing an expense report is a candidate for automation. To minimize the risk of fraud, the business analyst notes that different users can repeat the task UI through an approval chain.
• The Oracle Accounts Payable (AP) application that the organization currently uses can automate the pay expense report, so the analyst notes it as a possible solution.

Creating the Draft Model

To finish the first iteration redesigning the business process, the analyst defines it as a workflow process, and then meets with the usability analyst and the application developer to gather feedback. The business analyst uses the Workflow Editor in Siebel Tools to model the business process as a long-running workflow process. Figure 5 includes the workflow process that is not yet executable. The illustration serves as a way to communicate the design intention with other team members when accompanied with notes from the analyst.

Figure 5. Draft of a Workflow Process in Siebel Tools

Other team members notice that the model is not finished because the business logic for the approval is not clarified. For example, when is a single approval sufficient, and when are more approvals required for a single expense? Also, the team notices that the model does not cover the situation where a review step finds that the expense report is ineligible and Siebel CRM must reject it.

The business analyst modeled the workflow process in Siebel Tools, so the application developer can refine the model. Figure 6 includes the revised prototype that the developer can refine into an executable workflow process. At this point, the developer and the usability analyst possess a thorough understanding of the business process for expense reimbursement.

Figure 6. Refined Workflow Process in Siebel Tools

Next, the application developer creates an executable workflow process.

Creating an Executable Workflow Process

The business analyst used Siebel Tools to model the business process, which saved the application developer time because the developer can use the model that the analyst created as a starting point for iterative refinement. The application developer notices that, although logically it belongs in the business process model, the team must remove the submission task UI from the executable long-running workflow process because it must start the workflow process. The submission task must pass the ID for the expense report as an input argument. The developer decides to reuse the Object ID process property that the developer defines as an input argument to the workflow process. The developer communicates this refinement to the business analyst.

Next, the developer considers the Decision step that determines if further review of the expense report is required. The developer determines if it is best to call a business service that is dedicated to enforcing the review decision. The developer examines the Review task UI and realizes that Siebel CRM must assign it to a reviewer before Siebel CRM can instantiate it. The reviewer can use a business service step to call the Assignment Manager. This step resides immediately upstream of the review task. Figure 7 includes the executable workflow process.

Figure 7. Executable Workflow Process in Siebel Tools

These revisions to the draft business model help to illustrate the differences that exist in the level of abstraction between a business process model and an executable workflow process. The application developer continues to refine the workflow process. For example, creating conditional branches, process properties, input arguments and output arguments, and then testing and deployment, until the team is ready to implement the workflow process in a production environment. For more information, see Siebel Business Process Framework: Workflow Guide.

Next, the business analyst identifies the context for the task UI.

Identifying the Context for the Task UI

The business analyst must refine the task UI. The analyst begins by identifying the context for the task. The application developer notifies the business analyst that the submission task UI starts the long-running workflow process, so the analyst realizes that the user must manually start the submission task in a standard view. The analyst also realizes that most employees will frequently do this job task.

For these reasons, the analyst decides the development team must add the submission task UI to the Common Tasks task group, and concludes that the submission task does not require context passing. The context is the current record. For example, the record being submitted. The task UI that submits the record does not need to pass information about the submitted record to the next step in the business process.

The user must be able to frequently pause this task UI. For example, to provide the user a moment to find required documents. So the analyst decides that the task must use the description for the expense report as the value of the Context field in the Universal Inbox. This configuration allows the user to distinguish between different instances of the same task.

The analyst notes that Siebel CRM opens this task UI from the long-running workflow process, so the user opens it from the Universal Inbox. For this reason, the analyst does not add the review task UI to a task group. The review task does require that Siebel CRM pass an expense report number as an input argument. A Boolean value named Approved seems to be an appropriate output argument. The appropriate context for the Universal Inbox is a concatenation of the total amount for the expense report and the name of the submitter. For example, $450.00 from Aaron Jones.

Next, the usability analyst designs the task UI.

Designing the Task UI

The usability analyst now identifies activities in each task UI, and creates a prototype for the task. The Submit Expense Report task UI includes the following activities:

1. Create expense report header.
2. Create expense items.
3. Review and submit the expense report.

The usability analyst uses the Task Editor in Siebel Tools to model the task UI. The analyst defines the three activities as three separate task view steps. The analyst is not familiar with the View and Applet editors, so the analyst enters only the view step names without linking the view steps to the task views. These views do not yet exist.

The other task UI that reviews the expense report is a simple task UI. It requires only the Review Expense Report task view step.

For an example that includes view mockups that assist with designing a task UI, see Example of Developing a Task UI That Assists with Creating Multiple Opportunities.

Next, the usability analyst refines the task UI.

Refining the Task UI Design

At this point, the usability analyst is ready to work with the application developer, who is familiar with the Expense Report business object and the underlying data model for the objects. Together, they sketch the view layouts on a whiteboard. The application developer identifies the business components and applets that the Submit expense report and the Review expense report task UIs require.

The team must determine whether the user must create all expense items in the same view, or create each item in a separate view. The business analysis indicates that most users do this job task frequently. The business analyst and the usability analyst agree that productivity is more important than UI simplicity, and they conclude that the user must create all items in the same view. As an advantage of this top-down technique, the usability analyst realizes the possibility of reuse for two applets in two similar views. The third view that resides in the submission task UI displays the same data that the view that resides in the review task UI displays.