You can model data-entry forms and approval steps in MDriven Designer when you need users to find records, work on a business document, and move it through controlled business states.

Forms

MDriven applications use three form types:

Form type	What you use it for	Example
Seek form	Search persistent objects and show the results in a list.	A user searches for submitted expense claims before opening one claim.
Document form	Work on one root object and its associations through the navigation needed for a use case.	A user opens one expense claim, enters its details, and views its claim lines.
Report form	Present non-interactive, paginated information and expand master-detail combinations without cursor-based interaction.	A user produces a paginated report of claims and their claim lines.

A seek form can also be a modal seek and pick form, where the user finds one or more objects for a specific assignment. Use seek and pick for an association when a combo box is not suitable because there are too many objects to select from.

For example, an expense claim can have a 0..1 association to an approver. The document form can open a modal seek-and-pick form so the user can search for and assign the approver.

Start with AutoForms

AutoForms generate forms from the model and let you create test data and navigate the modeled associations before you design a tailored interface.

1. Create the classes, attributes, and associations for the process. For example, create an ExpenseClaim class with an association to its claim lines and an association to an approver.
2. Create and refresh AutoForms.
3. Use the generated seeker to create an ExpenseClaim, open its document form, and add or edit related claim lines.
4. Adopt an AutoForm when you want to keep manual layout or widget changes, or create a ViewModel from scratch.

Manual changes to an AutoForm are discarded during regeneration unless you adopt the form. An adopted form is kept and can be changed as your own ViewModel.

A ViewModel defines the interface for a use case.

Model an approval flow

Model an approval flow as business states and transitions on the business object. A state machine defines the allowed states and uses guards to enforce the business rules for moving between them.

For example, an ExpenseClaim can have these states:

• Draft — the claimant enters or changes claim information.
• Submitted — the claim is ready for an approval decision.
• Approved — the approval decision is complete.
• Rejected — the claim requires further work or is not accepted.

Use guards to prevent a transition when its business rule is not met. For example, the transition from Draft to Submitted can be guarded so that the claim cannot be submitted until the required information is present.

Put approval commands in the right context

Actions open forms, run code, and can be enabled or disabled from the state of their context. Use the action type that matches where the user performs the work.

Action type	Use it for	Approval example
Class action	An action on an object based on its class.	Make an Approve action available for an ExpenseClaim object.
Context action	An action for a particular document or seeker form use case.	Add a form-specific action that opens the approval document form from a claim seeker.
Global action	An action with no object or form context, such as a main-menu action.	Open a seeker for claims awaiting review.
Structured action	An action organized in a structure such as a sub-menu.	Group approval-related commands under an approval menu.

A class action appears where the type context matches. Review the action's matching ViewModel locations and opt it out where it does not make sense. For example, opt out an action that would reopen the same document form and give the user no meaningful navigation.

For an approval document form, use the selected ExpenseClaim as the root object so that the form shows the claim being reviewed. A modal form can also run optional code when it closes with OK.

Design checklist

• Use a seek form to locate records, a document form to work on one record, and a report form for non-interactive paginated output.
• Use a ViewModel for the approval use case when the generated AutoForm no longer matches the required layout or interaction.
• Keep data-entry feedback in UI validations and enforce state changes with state-machine guards.
• Enable or disable actions from the current context state so that users only see actions that apply to the current process step.
• Test the flow with an example claim: create it in Draft, enter its claim lines, submit it only when the guard allows it, and then run the approval or rejection action.

See also

• Documentation:How does MDriven work
• Documentation:State Diagrams
• Training:Bootcamp:Chapter 3