LeaderBoard

Requirements for Enabling Workflow in an Application Module [AX 2012]

To enable a Microsoft Dynamics AX workflow for a new or existing application module, you must complete a series of required steps and then, depending on application requirements, complete additional steps. This topic describes the required steps to add workflow to your application.


Required Steps

The following steps are necessary for every workflow:

  1. Create a state model. For more information about a recommended state model, see Workflow Approval State Transitions and How to: Enable a State Model for a Workflow Document.

  2. Add a workflow display menu item. The workflow display menu item is used to access the workflow types for each module. For more information, see How to: Create a New Module with Workflow.

  3. Create a workflow category. A workflow category filters workflow types to a single module. If adding a new module, extend the ModuleAxapta Base Enums type. For more information, see How to: Create a Workflow Category.

  4. Create a workflow document class to define the workflow document for the workflow. You will create a query, and if needed, add calculated fields to identify the derived fields available for conditions displayed in the workflow configuration tool. For more information, see How to: Create a Workflow Document Class.

  5. Enable a form or list for workflow. You must set properties on a form or list to display the workflow button and controls. For more information, see How to: Enable a Form or List for Workflow.

  6. Enable documents to be submitted to the workflow. For more information, see How to: Enable Workflow Submission.

  7. Create a workflow type. A workflow type defines information about which workflow document to use, tasks, automated tasks, approvals, line item workflows, workflow category, menu items, and event handlers. For more information, see Creating a Workflow Type.

  8. Activate the workflow. There are several ways to activate the workflow. For more information, see Activating a Workflow.

  9. Define and implement event handlers for the workflow, approvals, tasks, and automated tasks. For more information, see Handling Workflow Events.

  10. Implement workflow providers for due date, participant, hierarchy, and queue assignment. For more information, see Workflow Providers.

  11. Define and implement approvals, tasks, and automated tasks. For more information, see Creating Workflow Tasks, Automated Tasks, and Approvals.

Optional Steps

  1. Create custom workflow providers. For more information, see How to: Create a Custom Workflow Provider.

  2. Create event handlers for tasks. For more information, see How to: Create a Workflow Event Handler.

Hint : You can find and follow All mentioned topics related to this post at my blog.

About Workflow Development [AX 2012]

Workflow is defined as the movement of documents or tasks through a work process. In Microsoft Dynamics AX, the focus of workflow is on approval and task-oriented workflows. The developer role in Microsoft Dynamics AX is primarily to add workflow to existing business documents or create new documents that support workflow. This topic describes what the workflow life cycle is and the developer role for a workflow in Microsoft Dynamics AX.

Workflow can be described as structured or unstructured. In Microsoft Dynamics AX, workflow is structured and based on user interaction and system automation of business data. For example, when a purchase requisition (business data) is created it, workflow can be used to verify and approve the data.

Workflow Lifecycle

All workflows follow a basic life cycle as shown in the following illustration.

Workflow Lifecycle

You design the workflow based on customer requirements. The company administrator configures the workflow, and users run the workflow. This section describes the some of the main development concepts used in the design section of the workflow life cycle in Microsoft Dynamics AX.

Workflow types

The workflow type is a building block that can be used to create customized workflows that enforce business policies. The workflow type is defined in the Application Object Tree (AOT) at design time. The metadata from the workflow type is used by the customer to create a workflow configuration.

Workflow configurations

Workflow configurations are created by application administrators that use the Microsoft Dynamics AX workflow editor. The administrator configures the workflow, workflow elements, and approval steps that control the flow of the business document though the workflow process.

Workflow instances

A workflow instance is created by the workflow runtime when a workflow is activated.

Workflow elements

The elements of a workflow are created by you in the AOT and configured by application administrators. The workflow structure consists of sequences of workflow elements. An element can be a task, automated task, approval, or a sub-workflow.

Approvals are specialized workflow elements that allow for sequencing of multiple steps, which use a fixed set of outcomes. Tasks are generic workflow elements that represent a single unit of work which use custom outcomes defined by the developer. Automated tasks are workflow elements used to invoke X++ code within the application without requiring human intervention.

Work items

Work items are the units of work created by the workflow at runtime. They are the main interface between the end user who participates in a workflow and the workflow runtime. All work items for users who are logged on are surfaced in the Unified Work List and are used to inform a user about work assignments.

Developer Role

You must create the workflow artifacts, dependent workflow artifacts, and business logic to support the workflow. The following sections describe most of the developer artifacts used in a Microsoft Dynamics AX workflow.

Workflow Artifacts

  • Workflow type

    • Define the workflow document.

    • Define event handlers for workflow Started, Completed, ConfigDataChanged, and Canceled.

    • Define menu items used for the workflow type like Submit.

    • Define the workflow category.

    • Define required approvals, tasks, and automated tasks.

    • Enable and disable activation conditions.

  • Workflow category

    • Define the module that the workflow type is enabled in.

  • Approval

    • Define the approval workflow document.

    • Define approval event handlers for Started and Canceled.

    • Define approval menu items such as Document, Resubmit, and Delegate.

    • Enable or disable fixed approval outcomes.

    • Define approval outcome menu items for Action and ActionWeb.

    • Define approval outcome event handler.

    • Define the DocumentPreviewFieldGroup.

  • Task

    • Define the task workflow document.

    • Define task event handlers for Started and Canceled.

    • Define task menu items for Document, DocumentWeb, Resubmit, ResubmitWeb, Delegate, and DelegateWeb.

    • Enable or disable task outcomes.

    • Define task outcome menu items for Action and ActionWeb.

    • Define task outcome event handler.

    • Define the DocumentPreviewFieldGroup.

  • Automated Task

    • Define the automated task workflow document.

    • Define automated task event handlers for Execution and Canceled.

Dependent Workflow Artifacts

The following workflow artifacts are dependent upon the type of workflow defined in the AOT.

  • Workflow Document class - identifies the document query and any calculated fields.

    • Document query - defined in the AOT to expose data that is used for conditions in the configuration user interface.

  • SubmitToWorkflow class - displays the Submit to Workflow dialog box in the user interface, receives user comments, activates the workflow, and can update workflow state.

  • State model - tracks the state of the document in the workflow process, for example, Submitted, ChangeRequested, or Approved.

  • Event handlers for the workflow itself on the workflow type, approval, approval outcomes, automated task, task, and task outcomes.

  • Action and display menu items as well as classes which determine the action taken when a menu item is selected in the user interface.

  • Custom workflow providers.

  • canSubmitToWorkflow method - required on each table enabled for workflow.

How to: Enable a Form or List for Workflow [AX 2012]

In Microsoft Dynamics AX, each form or list that is to be used by workflow must be enabled for workflow. This topic describes the steps to enable a form for workflow. It also describes the steps to enable a list for workflow.

When a form is enabled for workflow, the workflow menu bar is automatically inserted at the top of the form, below the form title bar or action pane. The workflow menu bar provides everything that you must have to interact with a workflow. The menu bar contains workflow action buttons, such as Submit and Complete, and data fields that contain workflow instructions, configuration name, and information icons.

To display the Submit button, the form must have a canSubmitToWorkflow method.

Note: The form data source, or table, must contain a field for the workflow state of the document. For example, a field that contains the workflow state NotSubmitted should be updated to Submitted when the user clicks the Submit button on the form.

To enable a form for workflow
  1. In the Application Object Tree (AOT), expand the Forms node.

  2. Expand the form that you want to enable for workflow, and then expand the Designs node.

  3. In the Designs node, right-click the Design child node, and then click Properties.

  4. In the Properties sheet, set the following properties.

    Property Value
    WorkflowEnabled Set to Yes to enable the workflow menu bar on the form. The default setting is No.
    WorkflowDataSource Set to the same root data source specified in the query used for the Document property on the workflow type.
    WorkflowType Set to the workflow type that you want to use for the list.
  5. In the AOT, right-click the form, and then click Save.

To enable a list for workflow
  1. In the Application Object Tree (AOT), expand the Forms node.

  2. Expand the form for the list that you want to enable for workflow, and then expand the Designs node.

  3. In the Designs node, right-click the Design child node, and then click Properties.

  4. In the Properties sheet, set the following properties.   
    Property Value
    WorkflowEnabled Set to Yes to enable the workflow menu bar on the list. The default setting is No.
    WorkflowDataSource Set to the same root data source specified in the query used for the Document property on the workflow type.
    WorkflowType Set to the workflow type that you want to use for the list.

   5.    In the AOT, right-click the List, and then click Save.