Reports¶

A report gives process users a controlled, read-only way to explore existing data. The process designer chooses the data source, available fields, fixed filters, initial sorting, and standard views. Users can then filter, sort, group, pivot, and calculate supported aggregations while viewing the report.

Reports are built around the Pivot Table widget.

When to use a report¶

Use a report when users need to analyze existing process data without changing the data source or report setup. Use a screen when the page needs a custom form, data entry, initialization logic, or actions.

Setting up a report¶

Choose the data source, give the report a clear name and caption, and select the fields users need. The report designer validates the selected data source and fields. Report users do not need database access and cannot replace the selected data source.

Report settings¶

Choosing fields¶

Select the fields that should be visible to users. Prefer a small, meaningful set instead of exposing every available field. Include related fields only when they are needed. Keep personal, security-sensitive, and operational fields out of the report unless the audience requires them.

Fixed filters and initial sorting¶

Add fixed filters for rules that must always apply, such as showing only open requests or records from a specific department. Choose an initial sort order that helps users understand the first results.

Users can add their own filters and sorting while viewing the report, but cannot change the fixed report setup.

Report views¶

Named views are layouts prepared by the process designer. A view can define column visibility, order, widths, sorting, grouping, pivot settings, and aggregation settings.

Create and adjust views through the report designer. Users can select an available view, but cannot change the standard report layouts from the report page. Keep at least one detail-oriented view when users need to inspect individual rows.

Runtime behavior¶

Users can, depending on the report configuration:

• filter text, number, and date fields;
• sort fields;
• group rows;
• pivot columns;
• calculate supported totals, counts, averages, minimums, or maximums; and
• switch between designer-provided views.

These actions change the user's current view. They do not change process data or the report setup.

Access and URLs¶

Users must have access to the containing folder and the Reports feature. Administrative reports additionally require permission to administer or execute the process. Anonymous reports must be explicitly enabled.

Reports can be opened from the process folder or through their Emakin link. Share report links only with people who are allowed to see the report. If a report is missing, check folder access, the report audience, and whether the report is available in the active process version.

The report URL is:

1

https://mydomain.emakin.com/app/?/report/<process-id>/<report-id>

Performance and data exposure¶

• Prefer a focused set of fields over showing every available field.
• Keep relationships limited to the data needed by the report.
• Use fixed filters to reduce the initial result set where possible.
• Avoid exposing sensitive data unless the audience requires it.
• Consider the size of the data source when enabling unrestricted grouping, pivoting, or aggregation.

Related pages¶

• Screens
• Relational Databases
• Relational Database Query
• Pivot Table widget
• Insert Emakin Links to Forms or Reports