Generic maker/checker workflow for New & Edit actions across multiple forms in D365FO

(5) Share

Report

Posted on by MS-29011540-0

372

Hello all,
I hope you are doing well.

We have a customer requesting that more than 50 forms in Dynamics 365 Finance & Operations should support a maker/checker (approval) process for both New and Edit actions.

The proposed idea from the technical manager (who does not have a dedicated ERP development background) is to build a generic solution that can be reused across all forms, with no or minimal form-specific customization.

The suggested design is as follows:

Override New and Edit actions on any form.

Instead of opening the original form, open a generic runtime form.

This generic form dynamically:
- Reads the Data Entity schema related to the form.
- Creates UI controls at runtime based on entity fields.
- In case of Edit, populates the fields from the currently selected record.

Submitted data is stored in generic tables representing “pending requests”.

A separate generic approval form displays all pending requests (employees, vendors, customers, etc.) for approvers.

Once approved, the data is committed to the original business tables.

The same pattern would apply for New actions:

users enter data in the runtime-generated form, it is stored as a pending request, and only after approval is the real record created.

I have several concerns about this approach, including but not limited to:

Field-level validations (mandatory logic, cross-field validation, business rules)

Dynamic lookups and conditional logic

Security & role-based access control

Defaulting logic, computed fields, and events

Performance and maintainability

Bypassing existing form, table, and business logic

Handling special cases (composite entities, related tables, extensions, etc.)

From my experience, Microsoft typically implements maker/checker scenarios using staging tables and staging forms, specific to the business process.

A good example is Personnel actions in HR, where:

Actions (like creating a new position) are first stored in dedicated action tables.

Approvers review them in a separate form.

Only after approval are changes committed to the actual business tables.

This approach preserves business logic, validation, and security, but it is process-specific, not generic.

My question to the community:

Is a fully generic maker/checker solution (based on runtime-generated forms and Data Entity metadata) practically feasible in D365FO?

Are there known Microsoft-recommended patterns or guidance for implementing approvals on New/Edit actions across many forms?

What are the risks or limitations of such a generic approach in real-world ERP implementations?

Would a process-specific staging pattern be the correct architectural approach even if it requires more customization?

Any insights, experiences, or official guidance would be greatly appreciated.

Categories:

Dynamics 365 Finance

Microsoft Dynamics AX

I have the same question (0)

All responses (4)

Answers (3)

Verified answer

André Arnaud de Cal... 303,714 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi,

I will start with the answer: "Yes, it is possible to create a generic solution for this requirement".

However, it will take a lot of time, effort, testing, correcting specific details to achieve this. As product manager at my previous employer, I created a vision for Master Data Management, including data entry workflows and data quality.

Besides, the vision, we executed on this with a team and it took 14-18 months to have the solution supporting almost all scenarios. After that, the solution got extended with more features.

The solution is fully configurable with the option for multiple steps, so multiple people can contribute to a record before having it ready for approval. All data entry is tracked in a common staging table before data is copied to the target table(s).

My recommendation is to look at the Data Entry Workflow solution offered by Staedean instead of building something yourself. Link: Data Entry Workflow

1 people found this reply helpful.

Was this reply helpful? Yes No
Verified answer

Anton Venter 20,656 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

The proposal is not really feasible due to the vast amount of time it will cost to do this. Most standard forms contain a lot of business logic to support the related business process flow. You will have to reimplement a lot of all that to ensure the data created is correctly.

1 people found this reply helpful.

Was this reply helpful? Yes No
Verified answer

Martin Dráb 239,035 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!
The idea of editing data in a runtime-generated form instead of the existing forms doesn't sound wise to me. This would create parallel UI to existing forms, but one that ignores all the things that were done in the existing forms. For example:

Forms have UI designed for a particular purpose; they're not just a list fields (potentially a few hundreds). They have tabs, groups, grid/details views, actions (for example, Copy from on orders), fields that aren't exposed to users and so on.

A form often have more than one data source. For example, orders have lines, customers have addresses and so on. In my environment, CustTable has 16 data sources (12 in the standard forms and 4 added by extensions).

It would ignore all the logic in forms, such as business logic deciding which fields can be edited. This would lead to data inconsistency sooner or later.

I could bring more points, but these should be more than enough to reject such a design.

I think you should let users edit the data in the existing forms; anything else means a lot of effort to make things worse.

Regarding the existing pattern, one more to mention is the standard workflow framework. It maintains a status of records; a record is created the usual way, but it's created as a draft and its status changes when approved. Of course, business logics needs to take the status into account. This could be a solution for new records, but not for editing, where you require maintaining multiple versions of the same record at once. But it's supported in some cases. You mentioned customers, so you maybe interested how the standard approval workflow for customers does that. Look at CustTableProposal* tables and how they're used, e.g. modifiedControlledField() method of CustTable form.

Note that if you want to maintain multiple versions of the same record, don't forget to think about the update conflicts. If you allow editing of a record that has a pending change, applying the approved change may overwrite other changes.

1 people found this reply helpful.

Was this reply helpful? Yes No
MS-29011540-0 372 on at

Like (1)

Report
Copy link

Link copied!

@André Arnaud de Calavon @Anton Venter @Martin Dráb
Thank you for sharing you thoughts <33

Was this reply helpful? Yes No