AX1402

Managing process tasks using Save Type 4

Using Save Type 4, you can perform various actions on plan file process tasks within a spreadsheet, rather than using the Process task pane or the Process Status dialog. You might use this to:

• Provide end users with a custom utility to review and complete multiple plan file tasks at a time.
• Provide administrators and process owners with a custom utility to move plan files to different steps in the process.

This functionality can only be used on plan file process definitions. Standard process definitions cannot use Save Type 4 to complete tasks.

Save Type 4 depends on the placement of save-to-database tags within the sheet. There are three components:

• The primary SaveStructure2DB tag, which defines the locations of the save-to-database control row and control column, and specifies the desired operation.
• Column tags in the save-to-database control row, to specify the columns which hold the properties for the process action.
• Row tags in the save-to-database control column, to flag rows to be saved.

Save-to-database tag summary

Tag Type	Tag Syntax
Primary tag	[SaveStructure2DB; Axiom.ProcessActions; CustomSaveTag=Name]
Row tags	[Save]
Column tags	ProcessDefinitionID PlanCode Action StepNumber TargetStepNumber GenerateNotifications Comment

NOTE: Save Type 4 must be enabled for the sheet on the file's Control Sheet in order for the save process to occur. For more information, see Using Save Type 4.

Placing the primary save-to-database tag in the sheet

To define the save-to-database process, place the following tag in any cell in the sheet, within the first 500 rows:

The row containing this tag becomes the control row for the process, and the column containing this tag becomes the control column for the process.

You can also optionally use the custom save tag parameter. For example:

Defining the process action properties in the control row

Within the control row for the save-to-database process, specify the columns that define the process action properties. These properties can be placed in any column.

Column Tag	Description
ProcessDefinitionID	The database ID of the process definition. The specified process definition must be a plan file process definition.
PlanCode	The code of the plan file associated with the task. Save Type 4 is only supported for use with plan file process definitions, therefore, every task is associated with a plan code.
Action	The action to take on the task. The following actions are supported: Submit: Complete the task for an Edit Plan File step. Approve: Approve the task for an Approval step. Submit can also be used for this case. Reject: Reject the task for an Approval step. Move: Move the plan file to a different step. Regenerate: Regenerate tasks for the plan file, for the current step. Administrators and process owners can perform any of these actions on any task. Other users can submit / approve / reject tasks that they currently own. IMPORTANT: Non-admin process owners are not limited by their plan file filter, like they are in the Process Status dialog. They can perform actions on any task. Group owners, if applicable, cannot perform actions on all tasks in their group. They can only perform actions on tasks that they currently own. The Move and Regenerate actions follow the same rules as the corresponding actions in the Process Status dialog. For example, Move cannot be used on a sub-step of a multiple approvals step; it can only be used on the parent step. Regenerate can be used on either the parent step (to regenerate all active or skipped sub-steps) or a specific sub-step.
StepNumber	The current step number of the plan file. Required for all actions except Move.
TargetStepNumber	The target step number for the action. Required for Move actions; ignored otherwise. The target step must be a top-level step. The plan file will be moved from its current step to the target step.
Comment	Optional. A comment to store in the process history about the action. In most cases, this comment will be included in the notification email to the next step owner (if applicable). If the action is Submit / Approve / Reject, the notification settings in the process definition determine whether notifications will be sent. If the action is Move, then by default notifications are not sent unless the GenerateNotifications property is used to enable them. The comment does not apply if the action is Regenerate.
GenerateNotifications	Optional; only applies if the action is Move. Specifies whether a notification email will be sent to the next step owner as part of the move (True/False). If blank or omitted, notifications will not be sent.

The column tags can be placed to either the right or the left of the primary tag. All column tags are required except as noted above.

The control row must be dedicated to containing only valid column names for the Save Type 4 operation to the target table. Any invalid entries in the control row will cause an error when saving.

Flagging the rows to be saved

Within the control column for the save-to-database process, mark each row that you want to be saved with a [Save] tag. This is the only valid tag for the process save.

If you have defined a custom save tag in the SaveStructure2DB tag, then you must mark the rows with that tag instead of the default tag. For example, if your primary tag is [SaveStructure2DB; Axiom.ProcessActions; CustomSaveTag=SaveTask] then you would place the tag [SaveTask] in the rows that you wanted to be saved.

Only rows that are marked with a valid tag are processed; all other rows are ignored, even if there is content in the property columns. If a row contains a valid tag but no content exists in the required property columns, a save error will occur.

NOTE: The row tag can be placed within a formula if desired.

Populating task properties into the spreadsheet

The easiest way to populate the spreadsheet with the current task properties is to use an Axiom query to the Axiom.ProcessTasks table. For end users, this query is automatically filtered to only show the user's current tasks. For administrators and process owners, this query brings in all current tasks for all users. You can use the CurrentUserIsOwner column to filter the query for administrators and process owners if needed. For more information on the Axiom.ProcessTasks system table, see Axiom.ProcessTasks.

The following screenshot shows an example of how a workbook might be set up to provide end users with a utility to complete their process tasks in bulk:

When an end user opens the file, the Axiom query is refreshed to show the user's current tasks. The user can fill out the Action column to specify the action to perform on the plan file. The save-to-database control column is set up with a formula so that once an action is selected in the Action column, the save tag is automatically populated. When the user saves, the actions are performed via the Save Type 4 setup. The Axiom query should be set up to refresh after save, so that it is repopulated with the latest tasks after saving.

This example shows the control columns and rows to illustrate how the spreadsheet would be set up. Before rolling out this utility to end users, these work areas would be hidden via freeze panes and/or by using a view. Report headers and instructional text would also be added.

This utility could also be form-enabled, so that users could complete their tasks in bulk from a form. For example, the current tasks could be displayed to the user in a Formatted Grid component with Select tags to present the available actions. A Button component could be used to trigger the save-to-database.