You can control which actions users see in each ViewModel so that navigation and commands appear only where they are relevant.

What determines available actions?

MDriven Designer calculates available actions from the action type and the type context of each place in a ViewModel. An action can navigate to another view or perform work, such as calling a method on an object.

For example, a ShowRentalContract class action matches every ViewModel location that contains a RentalContract. This is useful when the user needs to open a rental contract from a list. It is not useful when the user is already editing that rental contract, so you can opt the action out at that location.

Action type	Where it is available	Typical use
Class action	Wherever an object of its associated class is shown and the type context matches.	Show or edit an object. For example, ShowRentalContract appears for a RentalContract in a search-result grid.
ViewModel action	Only in the ViewModel where you define it. Because it is not tied to a class, you control the ViewModel level where it appears.	A command specific to one view, such as assigning a selected customer in a rental-contract view.
Global action	In the top-level main menu.	Open a seeker or browser that is not rooted in one specific object.

Global actions build the main menu. For menu placement and the standard global actions, see Training:Global actions. For action names and their presentation text, see Training:Action names.

Match actions to the right ViewModel location

A class action is available where the class type matches. MDriven Designer updates the matching actions when you change a nesting's class.

For example, if a nesting is typed as RentalContract, matching RentalContract class actions are available there. If you change that nesting to another class, RentalContract actions no longer match and actions for the new class can match instead.

This automatic behavior gives you a useful starting point, but a matching action is not always appropriate. Use explicit action availability to remove irrelevant commands or to retain only the commands intended for a particular ViewModel.

Choose the default availability strategy

Since June 2025, a new ViewModel starts with matching class actions shown unless you explicitly opt them out. This default supports early modeling, when you want to discover and test available behavior quickly.

As the model grows, a ViewModel can match many class actions that are irrelevant to its specific use case. In that situation, use Default Opt-out on the ViewModel. With Default Opt-out, matching actions are not shown unless you explicitly opt them in.

ViewModel setting	Result for matching class actions	Use it when
Default behavior	Matching actions show unless you opt them out.	You are exploring a new view or most matching actions should be available.
Default Opt-out	Matching actions do not show unless you opt them in.	The ViewModel has a focused purpose and should expose a deliberate, small action set.

Turning on Default Opt-out preserves the current action set stored in the spans file, including existing explicit opt-ins and opt-outs. It changes how action availability is evaluated going forward; it does not remove the choices already recorded for the ViewModel.

Set the default for new ViewModels

To choose the starting behavior for ViewModels you create in the future:

1. Open the Package settings.
2. Set Actions - default opt-out on for new ViewModels to the desired value.
3. Create new ViewModels with the availability strategy appropriate for your model.

Convert existing ViewModels

If you have many existing ViewModels and want to move them to the Default Opt-out strategy:

1. In MDriven Designer, open the Extras menu.
2. Select Convert all Viewmodels to actions default opt-out.
3. Review the action availability in important views and explicitly opt in the actions that should remain available.

Opt an action out from a ViewModel

Use the ViewModelEditor when you are working on one view and want to control the actions visible at a particular ViewModel location.

For example, opt ShowRentalContract out from ViewAndEditRentalContract. The action would otherwise offer navigation to the view the user is already in.

1. Open the ViewModel in the ViewModelEditor.
2. Find the matching action at the ViewModel location where you do not want it displayed.
3. Press the > button to move the action to the opt-out column.
4. Save the model.
5. To make the action available again, press the < button to move it back to the opt-in column.

Opting out affects that action at that ViewModel location. The same class action can still be available at other matching locations.

Review availability in Action Cross Reference

Use the Action Cross Reference window when you need to review the relationship between one ViewModel and all actions that bring it up or appear within it.

1. Open the Action Cross Reference window for the ViewModel.
2. Review the actions that bring the view up. For example, a rental-contract view can be opened by both NewRentalContract and ShowRentalContract.
3. Review the actions that show in the ViewModel and the section or nesting to which each line refers.
4. Click a line to change its state between the default opt-in state (green) and opt-out (red).
5. Save and test the result.

If you already opted an action out in the ViewModelEditor, the corresponding line is shown as opted out in the cross-reference view.

Review a single action across all views

Use the ActionsEditor when you want to start from an action and identify every ViewModel location where it is shown or suppressed.

1. Open the action in the ActionsEditor.
2. Read the availability summary. For example, it can report that an action shows in two places and is opted out in one place.
3. Open the summary dialog.
4. Review each ViewModel and nesting where the action matches.
5. Click a line to toggle its opt-out state.
6. Save the model.

This view is particularly useful for seeker ViewModels. A seeker is an un-rooted view that helps users search or filter objects. It can contain both a root location and a result-grid nesting of the same class.

For example, SearchForRentalContracts can contain two RentalContract locations:

• The root location, which is always null because the seeker does not require a root object.
• A grid nesting that displays the search results from vSeekerResult.

ShowRentalContract may therefore match twice. Opt the action out at the null root location because no object can be selected there. Keep it available in the result grid, where the user can select a rental contract and open it.

Control ViewModel action level

A ViewModel action, also called a ContextAction, belongs to one ViewModel rather than to a class. It can theoretically appear at any level of the ViewModel tree, so restrict it to the level where it makes sense.

For example, a DeleteThis ViewModel action should appear at the Person level if it deletes the selected person. If you set it to the Car level, it becomes available only when a car is selected, which is inconsistent with its purpose.

In the Action editor, use the setting on the top-right side that controls the action level (only on this level). Select the intended ViewModel level, save, and test the view. For a guided exercise covering class actions, ViewModel actions, and ViewModel buttons, see Training:Bootcamp:Chapter 5.

Verify changes in the Prototyper

A running prototype continues to use the model version it loaded. After changing action availability, update the prototype before judging the result.

1. Save the model changes.
2. Either click Play again to start a new prototype window, or reread the model in the current prototyping session.
3. Navigate to the affected ViewModel.
4. Confirm that the action appears only at the intended location.

For the seeker example, after opting ShowRentalContract out at the null root and keeping it in the result grid, the action appears once: on the selected search result. Use Training:Prototyping to learn more about testing model and ViewModel behavior as you build it.

Design guidance

• Leave matching class actions visible while developing a new ViewModel when that helps you explore the model.
• Opt out commands that repeat the current navigation, such as a Show action on the view it already opens.
• In a seeker, remove object actions from locations that cannot contain an object, such as an always-null root.
• Use Default Opt-out for focused ViewModels that should expose only explicitly selected actions.
• Check action availability from both directions: use the ViewModelEditor for one view and the ActionsEditor for one action.
• Test every change in the Prototyper. Type matching can produce more than one action location in the same ViewModel.

Action visibility controls whether an action is presented in a ViewModel. Access rules are a separate concern; see Training:Access control system in MDriven.

See also

• Documentation:Actions
• Documentation:Turnkey session 3: Opting out actions
• Training:Global actions
• Training:Action names
• Training:Bootcamp:Chapter 5
• Training:Prototyping