AX1094

About process management

Process management can be used to manage and track an Axiom-related process from end to end—encompassing all aspects of the process, including steps that may need to be completed outside of the system.

Defining processes

In order to use process management, you first create a process definition. This file defines the properties of the process, such as:

• Name and description (for example "Annual Rollover")
• Process owner
• Steps in the process
• Owners and due dates for each step
• Associated files and features for each step
• Notifications to be sent during the process

Example process definition

The process definition is a file that is stored in the Process Definition Library (or for processes that belong to a file group, within the file group's Process Definitions folder). The process definition can be subsequently edited and "activated" as needed, whenever you need to perform and track the process. When a process is activated, a new incarnation of the process is created to track the details of that particular process instance. This ensures that you always have a history of each time the process is performed, including who completed each step in the process and when.

Performing a process

When you are ready to perform a process, you "activate" or start it. The first step in the process is made active, and a notification is sent to the assigned step owner (or owners). This default notification gives the user information such as the process name, the step name and description, and the due date. You can optionally customize the notifications for a process, and you can disable them if desired.

When a process is active, the process owner and all administrators can see the process in the Process task pane. Other users only see the process if they are the assigned owner of a step in the process.

The assigned user must perform the task and then mark the step as complete by the designated due date. For more information, see Step ownership and completing process tasks. If necessary, an administrator or the process owner can override step ownership and complete the step.

Once the currently active step is complete, the process moves to the next step, and so on until all steps are complete. Generally speaking, only one step at a time is active in a process. However, there can be multiple active steps at the same time if a Parallel Subprocess step is used in the process. When the active step is a parallel subprocess, all sub-steps of the subprocess become active simultaneously and can be completed in parallel. The subprocess is not completed until all sub-steps are completed. For more information, see Performing process steps in parallel. The Multiple Approvals Process Step also counts as a parallel subprocess.

When all steps in the process are complete, the process instance is automatically completed.

Step ownership and completing process tasks

Each step in a process represents a task to be performed, and that step has one or more assigned owners. When a step becomes active in a process, a task is generated for the assigned owner. This user is expected to perform the task for that step, and then mark the step as complete by its assigned due date. This is done using the Process task pane.

If a user is the assigned owner of an active step, the process and the active step display in the Process task pane (or in a custom task pane that has been configured to show the process task control).

The process task may be an activity that the assigned user performs in Axiom Budgeting & Performance Reporting, such as running an import, or it may be an activity that the user completes externally, such as obtaining the source file for the import from another system and saving it to the designated location. The task may be simply to confirm that the process is ready to continue (an approval step).

The step name and description should be defined so that the assigned user clearly understands what they are expected to do to complete the task. In some cases, the step may have an associated "action", such as the Open report button in the example screenshot above. This is provided as a convenience, so that the user can easily access features that are related to the task. However, once the file or feature is open, it is up to the user to decide what to do with that file or feature in order to perform the task. Axiom Budgeting & Performance Reporting does not perform any validation before allowing a step to be completed; it is up to the assigned user to determine that the step is complete.

Once the user has completed the task to their satisfaction, they can mark the step as complete by clicking the button in the task pane. This opens the Process Action dialog, so that the user can confirm that they want to complete the step, as well as enter any step comments.

This dialog displays slightly differently depending on step type. Most steps will display as follows, showing a step progression diagram for context:

NOTE: If the step is part of a Parallel Subprocess, then the step progression diagram is not displayed, because the process does not continue to the next step until all steps in the subprocess are complete. The user is simply informed that they are completing the current step.

Certain step types have slightly different step completion behavior. For example:

• If the step is an Approval Process Step, then the Mark step as complete button does not display in the task pane. Instead, the user can click either Approve or Reject. If they click Approve, the step is completed and the process moves to the next step. If they click Reject, the process is moved back to the prior step.

• If the step is a Scheduler Process Step, then the step displays in the Process task pane for information only, because the step will be processed and completed automatically by Axiom Budgeting & Performance Reporting. However, if the Scheduler job experiences errors, then the user has various options to restart the job or to manually mark the step as complete if the job does not need to be re-run.

In most cases, the current, next, and prior step owners show in the completion dialog. Prior steps and their owners only show when the task can be rejected back to the prior step. However in some cases, it is not possible or feasible to show the step owners. For example, if the next step in the process is a subprocess that may resolve to multiple steps with multiple possible owners, then Axiom Budgeting & Performance Reporting does not attempt to show the next steps or their owners. Instead it displays the name of the subprocess and that there will be "(multiple step owners)".

Once the step is completed, the process no longer displays in the user's Process task pane (unless the user is also the step owner of the next step). If the user has no active tasks in any processes, then the Process task pane will be empty for the remainder of the current session, and will not open the next time the user logs in (unless the user has been assigned a new active task in the meantime). Exceptions are as follows:

• Process owners see the process in their Process task pane as long as the process is active.
• The Process task pane is visible to administrators as long as any process in the system is active.

If necessary, an administrator or the process owner can mark a step as complete. For example, imagine that the assigned user already performed the necessary task but then left on vacation before they marked the step as complete. The administrator can mark the step as complete so that the process can continue. In this case the process history will reflect both the original assigned owner, and the fact that the administrator completed the step.

Performing process steps in parallel

In general, the order of steps in your process definition determines the order in which tasks for the process can be completed.

When the process is started, the individual steps are made active in the order they are listed. By default, each step is dependent on the prior step being completed (sequential steps). So if step 1 is the currently active step, step 2 is not made active and cannot be completed until step 1 is marked as complete. Once step 1 is completed, step 2 becomes active, and so on.

However, you may have some steps in your process that are not dependent on each other and can be completed in any order. These steps are known as parallel steps, meaning they can all be active at the same time.

To configure parallel steps, you must use a Parallel Subprocess step, and then define the parallel steps as sub-steps of the subprocess. This tells Axiom Budgeting & Performance Reporting that the sub-steps of the subprocess can be completed in any order.

When the Parallel Subprocess step becomes the active step, all sub-steps are also made active. Once all sub-steps in the subprocess are completed, then the Parallel Subprocess step is automatically marked as completed, and the process moves to the next step.

Imagine that step 2 of a process is a Parallel Subprocess step, and the subprocess has 5 sub-steps. Once step 1 is completed, then step 2 becomes active as well as all 5 of its sub-steps. The owners of the sub-steps can work on these steps and complete them in any order. Once all 5 of the sub-steps are completed, step 2 is automatically completed, and then step 3 of the process becomes the active step.

NOTE: The Multiple Approvals Process Step is a special type of Parallel Subprocess. It can only contain Approval Process Steps as sub-steps, but otherwise its behavior is the same as the Parallel Subprocess.

Tracking process status and history

Administrators and process owners can view process status and history at any time. Using the Process Manager dialog, you can see the status of all active processes or all current processes at-a-glance.

Example Process Manager dialog

Administrators and process owners can view the details for an active process, to see when each step was completed and by whom, as well as any comments added by users. You can also perform process administration tasks within this dialog, such as overriding step ownership, restarting stalled steps, and stopping the process.

Example process details in the Process Status dialog

Administrators can view the historical details for any process. For example, if you have a process that you run monthly, you can go back and view the prior month's details, or any amount of history that you want to retain.