You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

Where to start your DCM Dashboard application?

When using the DCM installation you can find you DCM Dashboard application using this url format:

This would result into the following DCM Foundation example.

When connecting the DCM Dashboard Service to Encore you also gain to ability to directly load your projects without exporting them manually, this is only available when the development-tools profile is active, using this url format:

This would result into the following DCM Foundation example.

What will it look like?

Assuming that you use a lot of Blueriq out of the box (like front-end, etc), and your DCM Dashboard application is based on the default DCM Foundation (v7.x) it will look mostly like the screenshots below.

When you start a "Main Dashboard" type of application that shows case lists to the user from which he can open running cases and/or start new cases:

When you open a case which embodies the start of a "Zaaktype_A" type of application, the user will see a case dashboard like this:

What typical building blocks does the Business Engineer make to get this result?

DCM Dashboard definition

The DCM Dashboard definition is the building block which knows what it entails to be a dashboard. It holds references of which Dashboard Widgets it should display and in what kind of layout. A definition is an collection of pages that are connected via events, these events are send by the Dashboard Widgets.

For example the widget "Niet toegewezen zaken" contains a button which opens the case of "ZaakType_A". By pressing the open button an event is thrown to which the dashboard (marked in blue) acts and locates the next dashboard page. 

DCM Foundation models

The DCM Foundation models contains the default setup on how to model a DCM Dashboard application. In the Foundation we have setup two Projects: "Main_Dashboard" and "ZaakType_A", one thing that could be noticed is that there is no single Flow which orchestrates flow of the application itself. The umbrella which ties all of the Flows together is the Dashboard Definition.

The image displayed at the DCM Dashboard definition shows two Flows "Mijn zaken" and "Niet toegewezen zaken", both of these Flows (aka widgets) are of type DCM Widget. By modelling a Flow as an DCM Widget it is possible to send DCM Widget Events back to Dashboard.

In the previous example at DCM Dashboard definition the widget "Niet toegewezen zaken" is modelled as a DCM Widget which send the open-case event to the dashboard. In this example dashboard application the "Case Dashboard" is then displayed, which is shown in the image above. It is not uncommon to display both Flows and Widget Flows in a single dashboard. There is however a caveat, Widget Flows hold the possibility to parse incoming event data which normal Flows do not. It is therefore good think about the consequences of using Flows vs Widgets Flows. 

A Widget Flow does not have to send an event, this is optional.


What typical configuration has to be done by the Business Engineer?

  • Create shortcuts on the Blueriq Runtime that the DCM Dashboard application can start
  • Create shortcuts on the Blueriq Runtime that the DCM foundation model needs to run
  • Create users in keycloak

What typical configuration has to be done by the Technical Engineer?


  • No labels

Didn't find the answer you were looking for? Try the advanced search!