The installation of Acumatica 2021R1 included the expansion of the new Workflow engine introduced in Acumatica 2020. While some standard screens are still waiting for their updates from Acumatica, this is the perfect time to begin migrating custom code to the new methodology.
A quick overview is worthwhile before getting into how to implement the new workflow engine for menu items. In simplified terms, the new workflow engine replaces Automation Steps. (Note that switching to the workflow engine requires disabling automation steps for those screens.) While Automation Steps could not be loaded into a customization project, the new workflow engine is configured there. The simplification of implementing screen configurations and business logic via a customization project instead of manual migration of automation steps is reason enough for me to jump on board! The Workflow engine provides a means to add actions, change field values, and so much more. This can be done via code or in the customization project. Acumatica’s standard approach seems to be to define the entire workflow in code and then allow users to implement changes via the customization projects screen. Unfortunately for those of us learning the changes, this leaves us with only complex examples to digest. With a Sys Admin who loved using Automation Steps to tweak screens, I found myself needing to add my custom actions to the screen but allow the Sys Admin to do all the configuration in the Customization Project. Yes, I’m that lucky! 🙂
In earlier versions of Acumatica, we simply used AddMenuAction to append the action to our Actions menu as a drop down selection. Further configuration was done in Automation Steps or event handlers.
In newer versions of Acumatica implementing the new Workflow engine, we need to update the screen configuration. The Workflow engine is highly configurable via code, as can be seen in the Acumatica Help. However, the example below simplifies the code to only add the action to the screen as a direct replacement for the code above. Multiple actions can be added in the code below by specifying more actions.Add lines.
Notice that the first step using workflow is to override Configure. Be sure to specify the Graph and Primary DAC in the first method and then define the new Configure method that will perform the actual screen update specifically for your graph. When updating an existing screen, use UpdateScreenconfigurationFor, but when adding a workflow to an entirely new screen, use AddScreenConfigurationFor. The usage is identical, but the Add will create a screen configuration whereas Update simply updates the existing one.
In the example above, the graph is InventoryItemMaint, but the action is defined in a graph extension called InventoryItemMaint_Extension. Since the action is in an extension, we need to specify the extension for actions.Add<GraphExtensionName>. If the action is in the base graph, simply use actions.Add(…) to include the action in the menu. Our action (printLabel) is named in the LINQ section, and we also specify to place it in the Actions menu there. Placing the menu item in the Inquiry menu is as easy as changing the folder specified to FolderType.InquiriesFolder.
That’s it! The Actions menu should contain the new action and support full customization with the workflow engine in the Customization Project. As mentioned previously, far more configuration can be done in code, but this completes the basic business requirement facing many of us as we move into the next major release of Acumatica.
Happy Coding!