Create and run reports

Reports answer questions about your automation — what's configured and what ran — and let you export the results. Operators and administrators both use them.

What this solves

Questions about what's configured and what ran get answered by hand (screenshots, ad-hoc queries, spreadsheets), which is slow and leaves no repeatable record.

What you can report on

Category	Examples
Configuration & reference	Agents, jobs, scripts, calendars, frequencies, tags, properties, resources, thresholds
Governance & access	Roles
Operational	Job history, event details by date, service requests

Build a report

To build and run a report, complete the following steps:

1. Go to Reports and choose what to report on.
2. Select the columns you want and arrange their order.
3. Add filters to narrow the results (text, number, single-select, or date/time; for example, a date range and an environment for job history).
4. Set the sort order.
5. Run the report to see results, then export to CSV or Excel if needed.

Checking a column adds it to the end of the column order automatically, so you only need step 2's ordering when you want a specific arrangement. Earlier builds could leave a checked column out of the order, and because results and exports follow the order, the column then showed in neither; a report saved in that state fixes itself the next time you open it.

Two filters that used to mislead

Both of these returned wrong results without any error, so a report built on either looked legitimate. If you have saved reports using them, re-check what they return.

Date filters now mean the whole day. A date filter takes a date while the values it matches are timestamps, so a date now means the entire day it names, in UTC — which is how the report's own date columns are labelled.

Operator	Matches	What changed
On	Anywhere within that day	Used to match nothing — only a value stamped at exactly midnight qualified.
Between	Start of the from day through the end of the to day	Used to stop at midnight of the to day, dropping that whole day's rows.
Before	Strictly earlier than that day	Unchanged.
After	Strictly later than that day	Used to include the named day; it now excludes it.

On, Before and After against one date now cover the timeline exactly once each. Note After is the one that returns fewer rows than before — add an On filter as well if you meant to include the day itself.

Is empty finds blanks that it used to miss. A text value can be blank either by holding an empty string or by never having been set, and the two look identical on screen. Is empty now matches both and Is not empty excludes both. On the Jobs report's Documentation filter and the Scripts and Roles reports' Description filters that is a large change: almost every job stores the empty-string form, so Is empty used to find close to nothing and Is not empty used to return everything, blanks included.

Save it for reuse

Save a report (its columns, filters, and sort) to re-run later. This is handy for a recurring month-end or compliance pull.

Change history isn't a report right now

The Audit History report has been withdrawn. It re-read each object's current state and inferred its history from it, so it showed one row for however many edits had really happened and the earlier values were already gone. Reporting on change history is being rebuilt on a real audit trail. A report you saved against it is still listed but can no longer be run — delete it.

The Governance & access category went with it at the time and has since returned, now holding the Roles report. Roles are a statement of what access is configured, not a history of who changed it.

Good to know

• Results are paginated and large sets show a truncation note; exports stream the full set.
• Job history's Workflow Name, Job Name and Agent Name filters take a * wildcard: payroll* is starts-with, *payroll is ends-with, and a value with no * still matches anywhere in the name. _ and % are literal now, so a filter of JOB_01 no longer brings back JOB-01 as well. See The Processes page.
• Job history has an Instance Name column and filter, for workflows that build as several named schedule instances per date. Filter it with Is empty to get only the workflows that don't. Note that Workflow Name in this report is the plain workflow name — the instance is in its own column, so you can paste a workflow name straight back into the filter.
• The Agents report can show Operator State and Effective Status, for agents deliberately taken out of service. To list agents that can actually take work, filter Operator State is Active — filtering on Status alone won't do it, since a marked agent is usually still connected.
• The Jobs report can show an Agent column plus Start Offset, Late to Start Offset, Estimated Run Time and Max Run Time — which answers "where does this run, and when is it meant to?" in one pull. The four timing settings belong to a job frequency, so selecting any of them returns one row per frequency and brings Frequency Name along automatically; unselect Frequency Name and the timing columns come off with it. A pool or a legacy agent group is labelled as such in the Agent column, so a bare name is a real agent.
• A report you can run may still show workspace ids instead of names. Reading the workspace list is its own permission (workspaces.view), so without it a report runs but shows ids where it would show names — and filtering or sorting on the workspace name is refused outright rather than matching nothing. Exports behave the same way. If a report's workspace column looks like identifiers, that is the permission to ask for.
• The Roles report is the access review in one pull: every role, its permissions, the workspace and environment pairs it applies to, and whether it is a built-in system role. Two columns read differently from how they look. Permissions can list more than you picked, because granting any action also grants that object type's view permission, where it has one. And Any in a Scopes pair means the role is unrestricted on that axis — Payroll / Any is every environment, not a blank. Filter System Role is No to see only the roles your team created.
• The Service Requests report is the quickest way to review a self-service catalog: it lists every request with its tags, workspace, version, and how many inputs and events each one carries. Sort by Inputs to find the requests a requester is most likely to fill in wrongly.
• Reports are read-only: running one never changes anything.
• Reports run on demand. Neither a report nor a saved search is delivered on a schedule or by email — run it and export the result when you need it.
• Saved reports are shared: everyone in your organization who can open Reports sees the same list, so give each one a name others will recognize. A name can be used only once.

Related topics

• Reports — full configuration reference and troubleshooting
• Use the event log (Operator)
• Search across OpCon Continuum (Operator)