Finance | Project Operations, Human Resources, ...

Workflow import works in test env., not in prod env. but works in unrelated env.

(3) Share

Report

Posted on by Dan P

284

Hi Dynamics Community,

I'm running into an issue which seems like it should be a non-issue, was hoping someone might have some input here.

I'm importing a workflow (Workflow approval for proposed vendor change) in a test environment, then running into an error and this stack trace when trying to import it in the production environment (see below).

However, when importing the same workflow in a totally unrelated environment, it works fine. So it shouldn't be an issue related to users or anything such.

Here's the error message, which seems to be just a stack trace:

at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.Dynamics.AX.Framework.Workflow.Model.AxMilClient.save(WorkflowModel _model, Boolean _isNewModel, Boolean _isNewVersion, WorkflowConfigurationVersionType _versionType)
at Microsoft.Dynamics.AX.Framework.Workflow.Model.WorkflowModelProvider.Save(WorkflowModel model, Boolean isNewModel, Boolean isNewVersion, WorkflowConfigurationVersionType versionType)

I tried using import option, the check box, to import to new version if there's a version conflict, no difference.

Since the stack trace starts with WorkFlowModelProvider, I figured I'd try to see if there's any problem with the model provider. Checking the XML-file for provider, I find this match: HcmPositionHierarchyConfigurableWorkflowProvider.

Checking that class, I see this description:

"Provider class for the configurable workflow hierarchy assignment provider.
Assignment is determined by the hierarchy configured to a given workflow."
Anyway, checking the position hierarchy and position hierarchy types, they are empty in both test and prod environments, that I can see.

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (7)

Answers (0)

Sort by

Layan Jwei 8,275 Super User 2026 Season 1 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi Dan,

I didn't get this error before but trying to help and think why, Is the code in PROD the same as in the other environments?

Perhaps the workflow is referencing something that doesn't exist in PROD yet. For example, maybe it could be using a field that hasn't been deployed there.

Could you also try creating the workflow from scratch in PROD? Is it a large workflow, or would it be relatively quick to rebuild? to see whether a particular step or configuration triggers the issue.

Was this reply helpful? Yes No
Suggested answer

Giorgio Bonacorsi 3,532 on at

Like
a
(3)

Report
Copy link

Link copied!

Hello,

My suggestion is to open the workflow in the test environment and check which configuration is applied for the approval (hierarchy, user group, etc.).
Then, in production, verify that the same configurations are present. The error likely occurs because the configuration in prod differs from test. When importing, D365FO tries to replace the connector but cannot find the required elements.

Thank you,
Giorgio

Was this reply helpful? Yes No
Abhilash Warrier 8,659 Super User 2026 Season 1 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi Dan,

Have you tried creating the workflow manually in the PRE-PROD or Production environment to troubleshoot the issue instead of importing the WF?

Please review the below option as well -

-> Validate workflow file, delete existing Workflow and try importing. Remember to take a backup since you are trying in PROD.
-> Verify all security roles exist
-> Validate workflow participants (user, role, hierarchy)
-> Check workflow configuration (steps, conditions, rules)
-> Compare environment setup (legal entity, dimensions, parameters)
-> Verify user permissions (workflow admin access)

Regards,

Abhilash

Was this reply helpful? Yes No
André Arnaud de Cal... 306,308 Super User 2026 Season 1 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi Dan,

Can you explain what you mean by an "unrelated environment"? Can you tell if there is a difference in software between your test and production environment? E.g. difference in the base version or a customization or partner solution?

Was this reply helpful? Yes No
Abhilash Warrier 8,659 Super User 2026 Season 1 on at

Like
a
(2)

Report
Copy link

Link copied!

As advised earlier, the best practice would be to manually recreate the workflow in PROD or the target environment since imports commonly fail due to hidden dependencies, environment-specific IDs, and hierarchy/provider mismatches. This would help troubleshoot the the issue and identify the root cause.

Was this reply helpful? Yes No
Suggested answer

Shaluma 369 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi,

The stack trace (HcmPositionHierarchyConfigurableWorkflowProvider) is pointing directly at it. Verify the Position Hierarchy Type exists and is published in Production before touching anything else. If that's broken, no amount of cache-clearing fixes it.

Reverse the cache/rebuild order Clear cache then rebuild metadata, not the other way around.
Please check version mismatch in test and prod

->Take the backup workflow XML

->Verify Position Hierarchy types match Production ( HR → Setup → Positions → Position hierarchy types)

->Delete failed/draft version

->Clear cache → Rebuild metadata

->Re-import → Activate the version

->Clear cache again, then test in prod.

Thanks,
If you found it helpful, please consider marking it as verified — it may be useful for others in the future!

Was this reply helpful? Yes No
Dan P 284 on at

Like
a
(1)

Report
Copy link

Link copied!

Thanks for the suggestions, all! They are very much appreciated.

I had another look at this issue today, trying to reflect on if there's any indication of what the source of the problem might be. Like I mentioned, the import works fine in an unrelated environment where none of the users, user groups or hierarchies are available, so the problem shouldn't be related to any setup required.

In the first test environment, where I suspect the workflow was initially created, I can't open the workflow editor. I think it's probably some issue with the web browser. I tried to locate trusted sites but couldn't find it in the web browser settings. Anyway, the import still worked fine. But I started wondering if it might be related to some other security issue, assuming there might be higher security settings in the production environment than in the test environment. Which I don't know for sure yet, it was only a hypothesis.

After this, having a look at the callstack messages again, I reflect on these two lines:

at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(...)
[...]
at Microsoft.Dynamics.AX.Framework.Workflow.Model.AxMilClient.save(...)

I checked what the AxMilClient is: Managed Interop Layer (MIL), It is heavily used in developer and testing environments—such as the Performance Benchmark SDK—to simulate the operations of the traditional desktop "rich client".

So, I wonder if there is some call during the import to a rich client, such as the Workflow editor, that for some reason differs between the production and test environments. Anyone familiar with what settings this might be?

Was this reply helpful? Yes No