When you select this flow type you will a number of options be set or become available (highlighted in the screenshots below):

1. The purple highlight: all DCM Widgets flows are by default set to exposed. This means they are the entry points of your Blueriq implementation models. Also you should not set this flow type for any other nested or non-DCM-Dashboard flow.
2. The blue highlight: for each entry point of the DCM Widget flow you can set request parameters in a specific tab of the property panel of the flow. In the first version of the DCM Dashboard these request parameters were handled by the AQ_RequestParameter service. Now we have made it a default feature of the flow type so your flow definition is not poluted with boiler plate defitions.
3. The green highlight: the DCM Widget flow has its own exit events. These events will communicate to the DCM Dashboard application. There are three specific events for all actions available in the DCM Dashboard. Each event requires its own parameters to be set, which then of course are linked to the entry point parameters. In the first version these exit events were managed with a service call that had to be modeled in the flow. Just like we did with the entry point we now made the exit events into native concepts to eliminate the need for boiler plate modelling.

Deleted the External flow contract and related mapping 

The "Home"-page with the different widgets modeled on it as containers is no longer needed.

Instead, the containers now have there own implemented DCM widget flows:

Deleted:

• the External flow contract and related mapping
• the Zaak_Dashboard modules and related mappings
• the Execute task module

Moved:

• Contents of the case intake (ZaakIntake) module has been moved into the Implementation module
• The ZaakA_Intake module itself has then been removed

The new DCM Dashboard application start DCM Widget flows from a regular Blueriq project. 

Each widget on a dashboard page can be modeled in a single DCM Widget flow