Workflow Configuration Displays Error Icon despite being valid

13 02 2018

I’ve recently found a scenario where my workflow configuration has an “invalid” icon next to the workflow configuration, this all despite the latest version being fully validated.


Tracing back the issue it seems that Microsoft displays the “valid/invalid” icon based on the latest workflow version sorted by workflow version “RecId” (See Table: WorkflowTable.validIcon).

So searching the workflow version Table I found an old invalid workflow configuration version (based on modifiedDateTime) that has an out of sync (i.e. newer) RecId than the actual newest versions. Deleting this record resolved the issue.

There should be no issues deleting this invalid version as actual workflow instances can’t be created against invalid versions.

I think the way the icons are displayed is a bug in AX, but so far doesn’t appear to affect too much.



Workflow Types in AX 2012

22 01 2015

Looking for a list of Workflow Types (Templates) available in AX 2012:

Mass Resume Line Workflows

14 11 2014

Orginally from my new blog:

<strong>Challenge/Problem</strong>: Many line level workflows that need to be resumed.

<strong>Description</strong>: Sometimes due to data or setups one may have numerous line level workflows failing and entering a “Stopped” state. This may be a result of calendars that do not have enough dates created, users who have been disabled etc… If the workflows were header level, it is easy enough to select all in the Workflow History form and click resume, however on line level workflows one needs to view each line level workflow individually and resume them.

<strong>Solution</strong>: The following job can be used to perform mass resume on stopped workflows. You can adapt the SQL to limit to certain documents or document types of necessary.
<pre>static void resumeStoppedWorkflows(Args _args)
WorkflowTrackinStatusTable tracking;
int i, j;
while select tracking where tracking.TrackingStatus == WorkflowTrackingStatus::Faulted
&amp;&amp; tracking.WorkflowType == WorkflowTrackingStatusWorkflowType::DependentSubworkflow
try {
Workflow::resumeWorkflow(tracking.CorrelationId, “Auto-resumed”);
catch (Exception::Error)
//Some may not be able to be resumed but we dont want to stop the process
info(strfmt(“%1 workflows resumed, %2 workflows could not be resumed”));

Deleting a workflow Instance in Microsoft Dynamics AX 2012

22 05 2014

Deleting a workflow Instance in Microsoft Dynamics AX 2012

I’ve been wanting to write a tutorial explaining the tables involved in a workflow and how to delete an instance if necessary (e.g. when a major fault or data inconsistency occurs), however it seems Colin’s Dynamics AX 2012 blog beat me to it and he did a superb job at that, check it out here

AX2012 – On Reassign: Failed to create a session

23 01 2014

When trying to reassign a record via workflow history in AX2012 we received the error: Failed to create session; confirm that the user has the proper privileges to log in to Microsoft Dynamics.

Screen Shot 2014-01-23 at 2.31.28 PM

The cause of our problem was a faulty CIL. We performed a full CIL compile, restarted AX and then were then able to perform the re-assign

Subworkflow Tutorial

13 01 2014

Since the launch of Dynamics AX 2012 I’ve been amazed at the amount of really good blogs that have started springing up. One such blog is Collin’s Dynamics AX2012 blog. After finding a whole load of question on Subworkflows in Dynamics AX, I considered writing up an article, but found a his tutorial very way more helpful than I could ever be, so please pay his site a visit!

Collin’s Dynamics AX2012 Blog – Subworkflows

JSON in Dynamics AX – Advanced example #1 (Basic Auth)

11 11 2013

After my previous post on using JSON in Dynamics AX2012 I have received a number of requests for some slightly more advanced examples. I will attempt over the next couple of weeks to provide some.

Today I will cover the use of Basic http authentication. There are a couple of non-intuitive tricks that one needs to use to get it to work.
Before performing any direct requests as per our previous example you will need to make some modifications to the headers in your RetailRequestWeb object.

The first header modification is to add the “Authorization: Basic ” header. You can do so by building up the header string as follows

System.Text.Encoding ascii;
str credentials;
credentials = "myusername:mypassword";
//N.B. Encode the credentials before adding them to your headers otherwise you will receive 403 unauthorized errors
ascii = System.Text.Encoding::get_ASCII();
credentials = System.Convert::ToBase64String(ascii.GetBytes(credentials));
//Combine header instruction and encoded credentials
request.parmHeader("Authorization: Basic "+credentials);

The second modification you need to make is set the request content type to “application/json” without this you may receive 403 unauthorized errors. The retails API allows you to set the content type easily by using the parmContentType method on your RetailRequestWeb object.


Finally the full example of constructing your json request ready for use:

RetailWebRequest request;
System.Text.Encoding ascii;
str credentials;

request = RetailWebRequest::newUrl(_url);
credentials = "myusername:mypassword";
ascii = System.Text.Encoding::get_ASCII();
credentials = System.Convert::ToBase64String(ascii.GetBytes(credentials));
request.parmHeader("Authorization: Basic "+credentials);

%d bloggers like this: