subworkflow document key

This question is not answered


I know this was asked for here before but never answered, although it appears lots of people are looking for the answer.

Since the Workflow Editor is not scalable, at around 200 elements it crashes even with 4GB of memory, I'm hoping that using subworkflows can solve the scalability problem. However, can someone please explain what a subworkflow “Document key” is? This has been asked all over the web and AX forums but no one seems to know. Microsoft simply says to select the document from the dropdown. There is nothing in the dropdown.

Any help would be appreciated!



All Replies
  • Jim, please see my blog post on this:

    Tutorial: Configuring Subworkflows in Microsoft Dynamics AX 2012 (

    I hope you find it useful.


  • Thanks Colin

    Unfortunately it didn't help. I don't quite know how to look at the class. But all of my workflows are type PurchReqReview. I'm assumng that they should all automatically be related to each other, but I suppose maybe not.


  • Hi Jim,

    Sorry that didn't work.

    The PurchReqReview workflow type has a document class called PurchReqDocument. It uses the query called PurchReqDocument (it has the same name). If you look at that query, you'll see that the data source is PurchReqTable.

    This is a very important piece of information. It means that any workflow type which you plan to use as a subworkflow must have, at the table level, the foreign key relationship I describe in my blog post.

    So, if you were expecting to use subworkflows to "take the load off" the primary workflow - because it is already heavily loaded with logic, I'm afraid that won't be possible...unless you are referencing a table with that foreign key relationship. But, it appears that you want *both* your primary workflow and subworkflow to use the PurchReqDocument workflow type. I do not believe this is possible, as the required relationship does not exist - and it can't exist because it's the *same* object. Subworkflows are designed to process related business process, not perform tasks within the scope of the primary workflow (thus my comment about not being "parent" and "child").

    It looks like you're struggling with a lot of conditions. Sorry about that - but it doesn't look like subworkflows will help in this case.


  • Thanks Colin

    Actually, what I'm trying to do is not all that complicated. We have about 150 approval workflows that are very straight forward, just a string of req approvals with ascending dollar limits. We have models so that any time we need to add a new workflow we just copy the whole thing and change the assignments. It's just that the last four  in every workflow are the same people. So when one of them leaves, I have to change 150 workflows. Since we have multiple approvers as backups, I actually need to change up to 3 elements to change one person. Which isn't all that bad, they don't change that often. But if they could be put in a subworkflow then I'd only have to change one subworkflow.

    We thought about writing a utility that would allow me to do mass changes, but the developers thought it would be too difficult.

    Ah, well.  I can live with it.

    Appreciate your input.


  • Hi Jim,

    I don't know what "too difficult" means (sometimes it means "leave me alone, I'm busy with something else") but in my investigations of the workflow engine in the AOT, I'm positive I worked with the data you're referring to - it was part of a different, more complex project. I'm away from my desk now but tomorrow I'll reply to this and let you know where to find that info. While there are almost 50 data tables dealing with workflow, that information is stored in only a few of them. Your developers should be able to write a job which can update those employee names for you, as long as the workflows can be clearly identified (by type, by name, by workflow id, whatever). You should not be forced to change 150 %!@&#-ing workflows - Dynamics AX should do the heavy lifting, not you.


  • Thank you Colin.

    If something can be written to mass change assignments in those top elements, then I assume it could change them at any level. That would simplify maintenance tremendously. I greatly appreciate your help.


  • Jim, your developers should have a look at the following tables. This is where the assignment, escalation and delegation data is stored.





    Of course, they will have to connect to the main workflow table which is "WorkflowTable".

    This assumes that you are NOT using work item queues, which are a totally different animal. They have their own tables but the idea is the same however.

    Anyway good luck - I hope they can solve this for you. It seems like a good candidate for automation.


  • Thanks Colin

    We did find a work-around. A workflow can't have as a subworkflow the same kind of workflow. So a Req Approval can't have a Req Approval as a subworkflow. However, it can have a related subworkflow. A Req Approval can have a Req Line Approval as a subworkflow. So, our Req Approval has a subworkflow of Req Line Approval. That subworkflow has nothing in it but a subworkflow of Req Approval and is set to automatically run. History looks a little funny and I wouldn't want to be the developer that has to write the report of the approval workflows. But it works quite well.



  • Hi Jim.

    Sorry for the really belated answer. Essentially the Document key is the field that links the parent workflow with the Subworkflow. E.G. If a purchase requisition workflow is kicking off a subworkflow then you would use the PurchReqId as the Document Key.