New April Hotfix and more changes for VAT
Check out the latest updates to Microsoft Dynamics GP 2016 and 2018.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
One of the main goals for the new workflow engine was to remove the dependency upon Share Point, as well as make it easier to create your own workflows in the system. As you will see in these articles, the code for the workflow engine resides mainly in Dexterity sanscript, as well as SQL procedures.
This series of articles will outline what you as a developer can do to create your own workflows. The entire process of creating a new workflow can be broken down into 5 steps, which will be broken down into more detail, if the need arises. These five steps are:
Create a workflow type constant.
Add workflow support to tables.
Add the record that defines the workflow type.
Add records for the Workflow Condition Editor content.
Add code to support the workflow actions from Dexterity windows.
The first decision you will need to make is how will your new workflow be identified throughout the system? To do this, you will need to create a new constant in your dictionary that will be known as your workflow type constant. For example, say we are creating a workflow for Item Approval. We would create a new Workflow Type constant as follows:
Notice that the format of the workflow constant should follow this construct: WORKFLOW_TYPE_XXXXX_APPROVAL. Creating your constant with this format will make it easier to add/modify code in the steps to come.
To enable workflow support for a particular business object, the table modification you will need to make is to add the field “Workflow Status” to the table that houses your business object.
For our Item workflow example, we will add the “Workflow Status” field to the IV_Item_MSTR table.
Once this field is added, you will need to author a conversion so your SQL Server database’s version of this table will match the table structure you have defined in the dictionary.
For this field, a set of pre-defined constants have been created and are available in the core dictionary. To set or reference this field, use the following constants:
Constant Static value
WORKFLOW_STATUS_NOT_SUBMITTED (1) Not Submitted
WORKFLOW_STATUS_NO_ACTION_NEEDED (3) No Action Needed
WORKFLOW_STATUS_PENDING_ACTION (4) Pending User Action
WORKFLOW_STATUS_RECALLED (5) Recalled
WORKFLOW_STATUS_COMPLETED (6) Completed
WORKFLOW_STATUS_REJECTED (7) Rejected
WORKFLOW_STATUS_NOT_ACTIVATED (9) Not Activated
The integration guide that comes with your install of Dexterity has a lengthy section (Part 10) detailing how to manually add the records via SQL scripting that will define your workflow type. This guide is titled IG.pdf and can be found in the Manuals subdirectory of your Dexterity install.
There is a shortcut implemented for this, a dex.ini switch QueryDesignerAllFunctionality=TRUE.
This switch will expose a “WF” button on the Workflow Maintenance window:
Pushing this button will open up the window that will allow you to define various attributes for your workflow type, without having to script the corresponding records in SQL.
I will define each field below. Saving this record will create the bulk of the SQL records needed to implement your workflow for your business object.
Workflow Type Name: This is your universal identifier of the workflow type that will refer to your business object. This string should match exactly what you set up for the constant value when you created your Workflow Type Constant.
Workflow Type Description: String describing your Workflow Type.
Dictionary ID: The ID of the dictionary that houses the table that contains the information for your business object. For our example, we are using the Item Master table, which is stored in the core dictionary (Dictionary ID of 0).
Form ID: This is the ID for the form that you would go to in order to create/edit/delete your business object. These actions can be done to items via the IV_Item_Maintenance (form ID 453) form.
Series: Typically, this will match the series your table and form belong to in the dictionary. For our item workflow, it will be placed in the Inventory Series.
Workflow Class: Another way to classify your workflow type. Typically, it will be the string representation of the series you chose.
Window Name: The name of the window in your dictionary that houses your business object. For our item example, the window name is IV_Item_Maintenance.
Fields List GUID: This will be created when you open the Workflow Condition Editor, which is outlined in the next step.
Workflow Type Business Object Key: This is a specifically-formatted string which will be used throughout the system to identify a specific instance of your business object. It has the following format:
Basically, it is a string that starts with the Physical Name of the table that stores your business object, followed by the physical names of the primary key fields of that table, all separated by the tilde character. You can specify up to a maximum of four key fields. For our item example, the Workflow Type Business Object Key would look like this: IV00101~ITEMNMBR
Workflow Type Historical Business Object Key: Same as the Workflow Type Business Object Key, except the table name would be the physical name of your historical table. If you do not have a historical table for your business object, then this field would be the same as your Workflow Type Business Object Key.
To define the fields and tables to be used as conditions for your workflow type, press the arrow to the right of the Fields List GUID, this will open up the Workflow Condition Editor.
From the Workflow Condition Editor, you can select the tables and fields that will be exposed to the user when setting up conditions for your workflow. For third-party applications, you can select your third-party tables here to include in your workflow conditions. Be careful to only include relevant tables and fields, as this window will allow you to select any field you want to, regardless if it is relevant to your particular workflow.
Now that you have essentially created all of the supporting SQL records for your new workflow type, the next blog post will detail how you will modify the form that houses your business object so it will recognize the new workflow type you have created.
It appears there are some missing steps in the Part 1 and Part 2 process.
Can I assume your are using Item Maintenance as an example of how MICROSOFT could add Workflow to Item Maintenance, and that you are not suggesting that a developer should add the Workflow Status field to a core GP table? This is an example of how a developer would add Workflow to a CUSTOM table?
Great post ! last week at the GPUG Summit there was a user asking the question relative to the WF 2.0 and the possibility that a new type could be added or not (specifically asking for Item creation :-) ).
Good job. Can't wait to get the next post.
Business Applications communities