Screens¶
Use screens when you need a process-backed user interface that does not start a new workflow instance. Typical uses include data-entry forms, lookup pages, dashboards, and operational tools for existing process data.
Screens use a data model to define their structure. A server-side initialization script can prepare data before rendering, and the screen can display or collect information through a normal Emakin form.
Please see the forms section for information on creating forms within screens.
For tabular data exploration, see Reports. Reports are designed for browsing and analyzing existing data, while screens are designed for forms and process interactions.
Dashboard views¶
Screens can be configured as dashboard views, automatically appearing in the dashboard folder. Dashboard screens are also available as panels inside the domain's dashboard designer.
This page focuses on how to design the screen itself. For domain-level navigation layout and audience-specific menu configuration, use Edit Screens.
Administrative views¶
Enable the administrative option to restrict access to process administrators. Only users with the required process permission can view these screens.
Anonymous access¶
Enable anonymous access when non-logged-in users should be able to open the screen. Anonymous access must also be enabled for the environment and the screen's link must be shared deliberately.
Form sections¶
Form sections control the default states of screen content. Formatting rules can further modify these states.
Screen URLs¶
Screens can be opened from the process folder or through their Emakin link. If a screen is designed to accept initial values from a link, those values are interpreted according to the screen's form configuration.
1 | |
Query string parameters can pre-populate the data model before rendering:
1 | |
Here, myfield and myfield2 are set to 1 and 2 respectively in the root of the data model. Nested fields can be set using XPath (for example, myelement/myfield3=3).