Screen Configuration: General Information

Each form of MYOB Acumatica (including existing and custom forms) includes a screen configuration—that is, the configuration of the screen that corresponds to the form. The screen configuration contains the configuration of the components of the particular screen, such as actions and fields, and the definitions of workflows.

When a form is created, a screen configuration of this form is empty. To define a workflow or to add configuration of components of a screen, you need to edit the screen configuration of the corresponding form. Some of the existing forms of MYOB Acumatica have predefined workflows, so their screen configuration is not empty.

In this chapter, you will learn how to edit a screen configuration and start defining a workflow.

Learning Objectives

In this chapter, you will learn how to do the following:

  • Determine the workflow's set of states of a record created on this form
  • Define the set of states for the workflow
  • Override the Configure method that contains the screen configuration
  • Locate the class where the predefined workflow is implemented
  • Create a graph extension where a customized workflow can be implemented

Applicable Scenarios

You will work with a screen configuration in the following cases:

  • You want to create a new workflow. You create a workflow when the form you want to customize does not have one, or when the existing workflow does not fit your business processes.
  • Update (that is, create an extension of) a predefined workflow. Customizing a predefined workflow can save you time over creating a custom workflow from scratch, especially if you want to make only minor changes to the functionality of the predefined workflow.
  • You want to add or update components of a screen configuration, such as actions or fields. You can configure actions and states of fields in a screen configuration even if they are not used in a workflow.

Components of a Screen Configuration

A screen configuration is defined by the set of components of a screen and the workflows in which these components are used. To configure a screen, you can define any of the following:

  • Conditions: To define conditions in a screen configuration, you use the WithConditions method. For details, see Defining Conditions.
  • Dialog boxes: To define dialog boxes in a screen configuration, you use the WithForms method. For details, see Implementing Dialog Boxes.
  • Fields: To define the states of fields in a screen configuration, you use the WithFieldStates method. For details, see Configuring Field States.
  • Actions and their categories: To define actions and action categories, you use the WithActions and WithCategories method. For details, see Implementing Workflow Actions.
  • Event handlers: To define event handlers, you use the WithHandlers method. For details, see Implementing Workflow Events.
  • Any number of workflows. For each workflow, you define the following:
    • Workflow states, which can include action definitions and field states

      To define workflow states, you use the WithStates method. For details, see Defining Workflow States.

    • Workflow transitions, which can be triggered based on conditions

      To define transitions, you use the WithTransitions method. For details, see Implementing Transitions.

    For workflow other than the default workflow, you also define the workflow-identifying field. This field holds the value that determines the workflow to be used.

The following diagram shows all components of the screen configuration.

Figure 1. Components of the screen configuration


A new screen has an empty configuration. Therefore, when you implement a workflow, you edit the existing screen configuration. To edit the screen configuration, you override the Configure method in an extension of the graph that defines the business logic of the screen.

Inside the Configure method, you define a workflow by using Workflow API (which is also called the screen configuration API). Workflow API has a strongly typed syntax. It has many compiler-based validations, which reduce the likelihood of an error. The API is made mostly of fluent generic methods, which use LINQ expressions.

Workflow Inheritance

In a customization project, sometimes a derived (or inherited) graph needs to inherit the behavior of the workflow that is defined in its parent graph because similar workflow behavior is needed in the derived graph. To cause the descendant graph to inherit the workflow behavior, you should specify the PXWorkflowInheritance attribute on the descendant graph. As the result, the descendant graph will utilize all workflow extensions of its parent. When a descendant graph is marked with the PXWorkflowInheritance attribute, you can define workflow extension for this exact descendant, and this extension will be applied strictly after all the extensions of the parent class. For details, see PXWorkflowInheritance..