A set of Service Desk Steps defines a process workflow.
In many cases a process cannot be defined as a static workflow. The workflow depends on conditions that influence and determine the workflow.
In the real world these conditions are described in contracts (internal services or external contractors) as Service Level Agreements. These SLAs can be abstracted to a list of rules. An SLA rule uses of a set of input parameters that determines a set of output parameters. These parameters are also called request and response parameters.
Each process starts with an end user request (a service request). Request parameters submitted will define the SLA to be applied and the corresponding workflow. Parameters that can determine the SLA and the workflow steps include factors such as location, requestor, equipment, and priority.
Each process consists of a standard workflow (independent of the SLA) and optional workflow steps (depending on the SLA). Using these optional workflow steps, you can create flexible workflows.
The standard workflow defines a required sequence of steps. The process will go to different phases, which is reflected by basic status changes. A basic status change is the trigger to activate additional workflow steps defined by the SLA. These workflow steps can be different for every use case and in turn have their own step status changes.
After a basic status change, the system checks for additional workflow steps. The standard process flow is interrupted. Setting the step status in the workflow table marks this. The process goes to one or more workflow steps, which result in step status changes. The standard process will proceed when all of the steps for this status is completed.
A step can also influence the standard workflow in some cases by changing the basic status.
ARCHIBUS provides fundamental steps that you can use in your workflow,
but you can also define your own steps. Every step implements
the step interface (com.archibus.eventhandler.Steps.Step).
The invoke method is the main method of the step and starts
the execution of a step. Distinction can be made between simple
"one-shot execution" steps and steps that require a response from a
user.
Examples of simple steps are notifications. No response is required. The step is invoked once and the action is logged. The system's internal step manager will proceed and search for the next step. A basic status change is also recorded as a step in the step log table. Setting the date_response and time_response marks the end of the step.
Examples of steps with responses are approvals, acceptance, and estimates.These require a response from a user. They are invoked and the step is logged in the log table. E-mail is sent to the user (or manager) that receives responsibility for the action. When the user responds to this invitation and completes the action, the record in the log table is updated. The system's internal step manager will continue with the step logic and search for the next step to be invoked.
When the last step within a basic status is completed , the standard workflow continues.