How to: Create a Workflow Category [AX 2012]

When you create a workflow type in Microsoft Dynamics AX, it must be assigned to a workflow category. The workflow category determines whether a workflow type is available in a specific module. If an appropriate workflow category does not already exist, you must create one.

For example, a workflow type for a customer invoice should not be available in the Master planning module. To make the workflow type available only in the Customer module, create a workflow category with the Customer module selected.

The following procedure describes how to create a new workflow category.

To create a workflow category

1. In the AOT, expand the Workflow node.
2. Right-click the Workflow Categories node, and then click New Workflow Category. A new workflow category group displays under the Workflow Categories node.
3. Right-click the new workflow category and then click Properties.
4. In the Properties sheet, set the following properties as required.

Property	Value
Name	The name that is used to reference the workflow category.
Label	The label used for the workflow category in the user interface.
Help Text	The description of the workflow category displayed in the configuration user interface.
Module	The module that the workflow will be available in. The default is Ledger.

After a workflow category is created, you can bind the workflow type to the new category. Typically, this is performed by the Workflow Wizard. The following procedure describes how to manually bind a workflow type to a workflow category.

To bind a workflow type to a workflow category

1. In the AOT, expand the Workflow node, and then expand the Workflow Types node.
2. Right-click the workflow type that you want to bind a workflow category to, and then select Properties.
3. In the Properties sheet, set the Category property to the workflow category created in the previous procedure.

How to: Create a New Module with Workflow [AX 2012]

In Microsoft Dynamics AX, modules are enabled for workflow. However, in some cases, you will need to create a new module that contains workflow. In each module that contains workflow, a Workflows list menu item must be added to the Setup pane. The following procedures are described in this topic:

• Creating a new module enumeration.
• Creating a display menu item for the Workflows list.
• Creating a menu for the new module.
• How to display the new menu in the client.

To Add a Module to the ModuleAxapta Base Enum

1. In the Application Object Tree (AOT), expand the Data Dictionary node, expand Base Enums, right-click ModuleAxapta, and then click New Element. A new enumeration displays under the ModuleAxaptanode.
2. Right-click the new enumeration, and then click Properties.
3. In the Properties sheet, select the Label property, and then enter the label of the new module.

To Create a Display Menu Item for the Workflows List

1. In the AOT, expand the Menu Items node.
2. Right-click the Display node, and then click New Menu Item. A new menu item displays under the Display node.
3. Right-click the new display menu item, and then click Properties.
4. In the Properties sheet, set the following properties.

Property	Value
Name	Set to WorkflowConfigurations<xxx> where <xxx> is replaced by a reference to the name of the new module. For example, you could set this value to WorkflowConfigurationsRecruit for a new module named Recruiting.
Label	Set text or a label that represents the text for the workflows list in the client.
ObjectType	Set to Form.
Object	Set to WorkflowTableListPage.
EnumTypeParameter	Set to ModuleAxapta.
EnumParameter	Set to the enum created in the preceding procedure.

1. In the AOT, right-click the new display menu item, and then click Save.

After the new module enum and display menu item are created, you can add them to the Menus node.

To Create a Menu for a New Module

1. In the AOT, right-click the Menus node, and then click New Menu. A new menu displays under the Menus node.
2. Right-click the new menu, and then click Properties.
3. In the Properties sheet, set the following properties.

Property	Value
Name	Set to a label or name of the new module.
Label	Set to a label that represents the text to display for the new menu in the client.

1. In the AOT, right-click the new menu, point to New, and then click New Submenu. A submenu node displays under menu node created in the previous step.
2. Right-click the new submenu node, and then click Properties.
3. In the Properties sheet, set the following properties.

Property	Value
Name	Set to Setup or another label that represents the text for the Setup pane in the client.
Label	Set to Setup or another label that represents the text for the Setup pane in the client.
NormalImage	Set to 3478. This will display a gears icon for the setup pane.
ImageLocation	Set to EmbeddedResource.

1. In the AOT, right-click the Setup node created in the previous step, point to New, and then click New Menu item. A new menu item displays under the Setup node.
2. Right-click the new menu item, and then click Properties.
3. In the Properties sheet, set the MenuItemName property to the display menu item created in the previous procedure.
4. In the AOT, right-click the new menu item, and then click Save.

After the menu for the new module is created, you must add a reference to the menu in the MainMenu node to display the menu in the client.

To Add a Menu to the Client

1. In the AOT, expand the Menus node, right click MainMenus, point to New, and then click Menu reference. The Select: Menus window is displayed.
2. In the Select: Menus window, select the new module menu that you created in the previous procedure, and drag the menu to the MainMenu node in the AOT.
3. In the AOT, right-click the MainMenu node, and then click Save.

How to: Enable a State Model for a Workflow Document [AX 2012]

Workflow documents in a Microsoft Dynamics AX workflow must implement a state model to represent the state of a workflow, approval, or task for a workflow document in the application. For example, a workflow document in the NotSubmitted state can be changed to the Submitted state when a user clicks the Submit button. This section describes how to enable the state model for a workflow document by using a class or by creating a method on a table.

The following table contains recommended states. However, the needs of your application will determine what states are needed, validation type for state transitions, and how many states are needed. For more information, see Workflow Approval State Transitions post.

For the state of the	Use
Workflow document	NotSubmitted Submitted ChangeRequested Returned Completed

Typically, the workflow state should be persisted in the root table of your workflow document data source. To add workflow state to a table, create an enum in the BaseEnums node of the Application Object Tree (AOT) that contains the workflow states shown in the previous table. The first enum defined should be the NotSubmitted enum, and this will also be the default setting in the table. After the enum is defined, drag the enum to the Fields node of the workflow document data source table.

After a state model is defined, you can enable forms and lists to work with workflow. For more information, see How to: Enable a Form or List for Workflow post.

Note : Workflow state can be implemented in many ways. The following procedure shows one way of performing this task.

To create a state change manager class

1. In the AOT, expand the Classes node.

2. Right-click the Classes node, and then select New Class. A class group displays under the Classes node.

3. Right-click the new class, click Rename, and then enter a name for the class.

4. Right-click the new class and then click New Method. A method node named method1 displays under the Classes node.

5. Right-click method1 and then click Edit. Enter the following code for the started event method.

   X++

   public static void started(RecID _recID)
   {
       <insert method here>
   }
   

   
   
6. 
   

   Repeat steps 4 and 5 for the remaining states.

Example

The following code is part of the setWorkflowState on the PurchReqTable Table. This method sets the workflow state field in the table and updates the user interface with a user friendly status, and then updates the state in the database.

X++

static void setWorkflowState(RecId _purchReqRecId, PurchReqWorkflowState _purchReqWorkflowState)
{
    // Declare variables.
    PurchReqTable purchReqTable;

    ttsbegin;
 
    // Selects the record to be updated based on the recId and then
    // sets the workflow state. 
    purchReqTable = PurchReqTable::findRecId(_purchReqRecId, true);
    purchReqTable.State = _purchReqWorkflowState;

    // Based on the workflow state, the status in the user interface
    // is updated with a user friendly status.
    switch (_purchReqWorkflowState)
    {
        case PurchReqWorkflowState::Submitted:
            purchReqTable.Status = PurchReqStatus::Submitted;
            break;
        case PurchReqWorkflowState::NotSubmitted:
            purchReqTable.Status = PurchReqStatus::Draft;
            break;
        case PurchReqWorkflowState::Completed:
            purchReqTable.Status = PurchReqStatus::Completed;
            break;
        case PurchReqWorkflowState::Returned:
            purchReqTable.Status = PurchReqStatus::Rejected;
            break;
        case PurchReqWorkflowState::ChangeRequest:
            purchReqTable.Status = PurchReqStatus::ChangeRequested;
            break;
    }
 
    // Commits the state to the database. 
    purchReqTable.update();
 
    ttscommit;
}

Workflow Approval State Transitions [AX 2012]

Microsoft Dynamics AX workflow documents that are enabled for workflow approvals typically support at least five workflow states. The current workflow state of a workflow can be maintained in a table field associated with the workflow document. As the state of the document is changed, the state field in the table should be updated. This topic describes workflow approval states.

Workflow State

Workflow state determines what you can do with the workflow document as soon as it is available in the system. Workflow states are defined by developers and must be supported in queries and business logic for operations that are controlled by workflow. Workflow approvals typically use the following workflow states.

 

Workflow state	Use
NotSubmitted	The state of the document before it is submitted to workflow or if the workflow is canceled. This is the state of all documents before a workflow instance is instantiated for the document.
Submitted	The state of the document as soon as the workflow is activated and the document is submitted to workflow. This is a temporary state when the user activates a workflow, but the system has not yet processed the workflow for activation.
PendingApproval	The state of the document as soon as the approval starts and remains in this state until the approval is completed, returned for a change, or rejected.
ChangeRequested	The state of the document if a change is requested or the document is returned.
Approved	The state of the document when the approval is completed.

The following diagram illustrates a typical approval state transition model.

Here are some general guidelines for workflow state:

• Avoid creating your own workflow states unless you have a business justification for doing this.

• Consider refactoring existing approval states so that you can take advantage of the states listed here.

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.

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.