AX1336

About plan file processes

The Process Management feature supports a special type of process for file groups, known as a plan file process. Plan file processes are used to manage the progression of plan files through a set of edit and approval steps.

When using plan file processes, you can define a set of steps for plan files to progress through, assign owners to each step, and control the level of edit rights at each step. You can set due dates for each step, and review the process status periodically, so that you have a constant view of where all plan files are in the process.

Defining plan file processes

Plan file processes are defined by using a dedicated process type known as a plan file process definition. Plan file process definitions only allow steps that focus on editing and reviewing plan files. No other process step types are allowed.

Plan file process definitions can only be created within a file group, and are automatically associated with the file group they belong to. If a file group is cloned and the processes are included in the clone, the processes in the new file group will automatically be associated with the new file group.

The plan file process definition defines the properties of the process, such as:

  • Name, display name, and description (for example "2022 Budget Process")
  • Process owner
  • Steps in the process
  • Ownership assignments and due dates for each step
  • Notifications to be sent during the process
  • Optional configuration settings for Web Client process pages

Plan file process steps

Plan file processes support three kinds of process steps:

  • Edit Plan File: This step type allows the step owner to edit the plan file. Owners of Edit Plan File steps have read/write access to plan files, and can save plan data to the database. It is assumed that these owners will be developing plans and making changes to plan files. Owners can submit their files to the next step, but cannot send files back to a prior step.

  • Approval: This step type allows the step owner to approve or reject the plan file. Owners of Approval steps have read-only access to plan files, unless read/write access is explicitly granted for the step. It assumed that these owners will be reviewing the plan files and then either approving the plan files to send them to the next step, or rejecting the plan files to send them back to a prior step. The rejection behavior is configurable at the process level and the individual step level, so that you can specify which step the plan file is rejected back to, or allow the step owner to decide which step to reject back to.

    Plan file processes for on-demand file groups also support an optional ability for approvers to stop the plan file in the process entirely ("deny request").

  • Multiple Approvals: This step type allows multiple Approval steps to be active simultaneously instead of sequentially. All of the step owners must approve the file before it can progress to the next step in the process.

    For example, imagine that you have two different approvals that need to be obtained for a plan file process. If these approvals should be sequential—meaning that the first approval must be obtained before the plan file progresses to the second approval—then you should use two regular Approval steps in a sequential order. But if the two approvals can occur in any order, then you can use the Multiple Approvals step with two Approval sub-steps, so that both owners can approve the plan file concurrently.

The following screenshot shows an example plan file process for a budget process. When the process is active, each plan file in the file group will progress through these steps independently.

Example plan file process (as a plan file process definition)

This process has three Edit Plan File Process Steps and two Approval Process Steps. During the edit steps, users can access and edit the plan file, and then move it on to the next step when done. During the approval steps, users can access and review the plan file (and optionally edit it), and then either approve it to the next step or reject it to a prior step.

Alternatively the process can use the Multiple Approvals step for concurrent approvals. In the following example, The Management Approval item is a Multiple Approvals step with two Approval sub-steps. When the Multiple Approvals step becomes active, both the VP and Finance approvals will become active at the same time, and can be completed concurrently. Once both owners have approved the step, the plan file moves on to the final Board Approval step.

Example plan file process with a Multiple Approvals step

Ownership assignments and access to plan files

Each step in the plan file process has assigned ownership. When a task is generated for a plan file, the task owner has the responsibility to complete the task and then progress the plan file in the process.

You can assign a user or role directly to the step, or you can look up the ownership dynamically for each plan file using a designated table column or a workbook. For more information on assignment options for plan file process steps, see Assigning owners to plan file process steps.

If some plan files do not need to complete a particular step, then you can configure the ownership assignments so that those plan files will skip the step. The assignment must use either a table column or a workbook. Using these options, you can enter the keyword [skip] as the owner assignment to cause a plan file to skip a particular step.

If the process has certain aspects that are conditional, then the best approach is to use the workbook assignment option. For example, in a capital process you might want to assign different owners depending on the amount of the capital request. Or, you might want to include or skip an "IT Review" step depending on the nature of the capital request. When using the workbook assignment option, you can include logic in the workbook that looks up other values and determines who the owner should be (or if it should be set to [skip]).

If a user is assigned as a step owner for a plan file in a plan file process, the user must have a file group permission set that includes the plan file. If the plan file is not included in any of the user's permission sets (either directly configured or inherited through a role), then the user cannot be the step owner for the plan file and the plan file will stall in the process.

If a role is assigned as a step owner for a plan file in a plan file process, then not all users in the role will become step owners. Instead, ownership is limited to users in the role who have a file group permission set that both includes the plan file and that has Interacts with Process Management enabled. If no users in the role meet the criteria for ownership, then the plan file will stall in the process.

When a user is the owner of a plan file for an active process step (either directly or via a role), process management will "elevate" the user's security permissions as necessary so that the user can complete the task. In summary:

  • For Edit Plan File Process Steps, the user will be elevated to Read/Write and Allow Save Data. This allows the user to access the file with edit permissions, and save data.

  • For Approval Process Steps, the user will be elevated to Read-Only access so that they can access and review the file. If the option Allow reviewers to edit the plan file is also enabled, then the user is elevated to Read/Write and Allow Save Data so that they also have the option to edit the file and save data.

For more information, see How plan file processes and security interact.

Activating the process and completing process tasks

When you are ready for the planning process to begin, you "activate" or start the process. The behavior of the process depends on whether it is for a standard file group or an on-demand file group:

  • For standard file groups, typically all plan files are created before the process is started. All plan files become active in the first step of the process and tasks are generated for the owner(s) of each plan file for that step. Plan files then progress through the process steps as owners complete their tasks. Once all plan files have completed all steps, the process is automatically completed.

  • For on-demand file groups, typically the process is started before plan files are created in the file group. As end users create plan files "on demand," the plan files are automatically started in the process and tasks are generated for the owners of the first step. Plan files then progress through the process steps as owners complete their tasks. On-demand processes remain active until they are manually stopped, to accommodate the continued creation of new plan files.

In the Desktop Client General term for using either the Excel Client or the Windows Client, both of which are installed to the user's desktop., tasks for a plan file process display in the Process task pane. Task owners will also receive a notification of the new task, if the step is configured to send notifications. Notifications can be delivered by email and/or the Notifications task pane, and can be customized as desired.

Example Process task pane with plan file tasks

Task owners can open the plan file from the Process task pane. They can double-click a plan code to open that specific plan file, or they can click the Open button to launch the Open Plan Files dialog, which is filtered to only show the user's currently assigned plan files.

Task owners can complete tasks by using the Mark step as complete option in the task pane for edit steps, or the Approve and Reject options for approval steps. If the user currently owns multiple plan files in the step, the user will have the option to select multiple plan files to complete in batch. The user also has the option to enter a comment for the next step owner.

  • If the user completes or approves the task, then the step is completed for that plan file. If the current step is an edit step or a regular approval step, then the plan file is moved to the next step. If the current step is a sub-step of a multiple approvals step, then the sub-step is completed and the plan file will only move to the next step when all sub-steps are completed.

    NOTE: If Save and validate plan file before advancing to next step is enabled in the process definition, then the plan file will be validated and saved in the background before the task is completed. If an error occurs that prevents the save, the user will be informed of the error and the task will not be completed.

  • If the user rejects the task, then the step is rejected and the plan file moves back to a prior step. In the case where the current step is part of a multiple approvals step, the rejection of any sub-step causes the parent multiple approvals step to be rejected.

  • For plan file processes for on-demand file groups only, owners of approval steps may have a third option of Deny Request (the specific wording of the option can be customized). If the user chooses to deny the request, then the plan file is aborted in the process and no longer progresses.

Example task completion dialog for plan file tasks

Task owners can also complete tasks as part of saving the plan file. For more information, see Prompting users to complete process tasks when saving plan files.

In most cases, the current, next, and prior step owners show in the task completion dialog. Prior steps and their owners only show when the plan file 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 multiple plan file tasks are being completed at once, each plan file could have different and multiple step owners. In this case Axiom Financial Institutions Suite does not attempt to show the step owners and simply indicates "(multiple selections)".

Process features for the Web Client

If the plan files in the process are form-enabled, then most or all task completion will likely take place in the Web Client. Axiom Financial Institutions Suite provides a variety of resources for end users to complete their tasks in the Web Client, however, it is the responsibility of the file designers to make these resources available to end users. For example:

  • If you want users to be able to complete the current process task from within the form-enabled plan file, then the form must be set up with a Button component that provides the functionality to submit, approve, or reject the current task.

  • The Process Summary component can be used to provide users with a summary of their current tasks, for a particular process. Typically this component is placed on a form-enabled Home file.

  • The Process Directory page allows users to review process status for all plan files they have access to, and complete their current tasks for a particular process. This page can be accessed from the Process Summary component, or you can include a link to this page on a form-enabled Home file or other Axiom form, or in a task pane.

  • The Process Routing page allows users to review the process history of a particular plan file. If the user is the current step owner, they can also complete the task from the page. This page can be accessed from the Process Summary component, or you can include a link to the page on a form-enabled Home file or other Axiom form.

  • The Process Tasks page allows users to review and complete their current tasks for a particular process. You can include a link to the page on a form-enabled Home file or other Axiom form.

For more information, see Web pages for plan file processes.

Tracking process status and history

Administrators and process owners can check the status of the process at any time using the Process Status dialog. In addition to the overall process status, they can check the status of individual plan files to see which step the plan file is currently active in, the process activity of the plan file, and any comments made by owners of the plan file.

Example plan file status in the Process Status dialog

Process administration tasks can also be performed within this dialog, such as moving plan files to different steps, regenerating tasks for stalled plan files, and stopping the process. For more information, see Managing active plan file processes.

Axiom Financial Institutions Suite also provides a variety of reporting options that can be used to keep track of the process. You can build your own reports using Axiom queries that incorporate process information, and by using the GetProcessInfo function. You can also reference the built-in Time-in-Step report that is available in the Web Client. For more information, see Reporting on plan file processes.

Handling plan files with different process requirements

Plan file processes can easily handle minor differences in process requirements for plan files. For example, if some plan files don't need to complete a particular step, they can skip that step. You can also use dynamic owner assignments to accomplish conditional ownership, such as to assign a plan file to a different reviewer if the plan file exceeds a certain amount.

However, larger organizations that are comprised of distinct groups, sites, or facilities may have more significant differences in process requirements. Plan files may need to start the process at different times and be managed by different users. In more extreme cases, the groups may need different steps, assignments, notifications, and other process properties that cannot be reconciled within a single process definition.

Plan file processes provide two features that are intended to help meet these needs:

  • Grouping Column: You can specify a grouping column for the process, so that each group can be managed individually within the process. The plan files in each group can be started at different times, and can be managed by group within the Process Status dialog. For more information, see Managing a plan file process by groups.

  • Process Filter: You can specify a filter for the process, so that the process is limited to a subset of plan files. This allows you to have multiple active process definitions that can be started at different times, managed separately, and configured to the precise needs of each subset. The filters on the process definitions cannot overlap—although multiple processes can be active for the file group, each plan file can only be active in one process. For more information, see Using a process filter to limit plan files in the process.

If your process requirements can be met by a single process that uses the grouping column feature, then it is recommended to use that feature due to the lower system overhead and simplified maintenance. Although the process filter approach provides more flexibility to accommodate differing needs, having multiple processes introduces more setup and maintenance, and places a heavier processing load on the system. Additionally, using multiple processes has limitations. Certain features, such as the Process Directory in the Web Client, only support showing one process per file group.

NOTE: The grouping column and filter features are only available for standard file groups. On-demand file groups must use a single active process, so that newly created plan files are automatically started in that process.