Reports

Task walkthrough: Create and run reports. This page is the full configuration and troubleshooting reference.

Reports let users query the platform's configuration and history and export the results. A report is built by choosing columns, sorting, and filters against a chosen object; reports can be saved and re-run.

Report catalog

Category	Objects you can report on
Configuration & reference	Agents, Calendars, Frequencies, Jobs, Scripts, Tags, Properties, Resources, Thresholds
Governance & access	Roles
Operational objects	Job History, Event Details (by date), Properties, Resources, Service Requests, Thresholds

Columns worth knowing about

Report	Column	What it does
Properties	Value	Shows each property’s value, filterable by Contains, Equals, Is empty or Is not empty, and sortable. A value on an encrypted property is masked. Only the 50 most recent values are looked up; beyond that the column reads (unavailable). Is empty finds the properties whose value is deliberately empty — an optional setting left unset; it does not match a property whose value was merely not looked up, which is excluded from a filtered result either way.
Calendars	Date	One row per date, replacing the old Date Count. Per-date detail is capped at 500 calendars — above that, run the report on a narrower selection.
Resources	In Use	Active allocation units for the resource, summed across every environment — not just the one you are looking at. Filterable by Equals, Greater than, Less than, and sortable. Compare it against Total to see remaining headroom.
Jobs	Job Type	Reports the job's actual type. Earlier builds read a field that did not exist, so every row came back Unknown; a job with no type still reads Unknown, and the filter now matches those rows. The values are internal type names — run-command, unix-command, windows-command — not the display names in the job type picker.
Agents	Operator State	Whether the agent has been marked out of service — Active, Marked Offline, or Marked Draining. Filterable and sortable.
Agents	Effective Status	The single value the agent lists show, combining observed connectivity with any operator mark. Available as a column and sortable, but there is no Effective Status filter — filter on Status or Operator State instead.

Status and Operator State are separate on purpose. A marked agent usually stays connected, so it still has a Status of ONLINE. Filtering Status is ONLINE therefore includes agents that can take no work. To report on agents that are genuinely available, filter Operator State is Active as well.

Jobs: agent and per-frequency timings

The Jobs report answers where a job runs and when it is expected to run. Five columns carry that:

Column	Reads	Shown as
Agent	The job's agent assignment	PROD-AGENT-01 for a single agent, PROD-POOL (Pool) for a pool, AllUNIX (Legacy Group) for a legacy agent group
Start Offset	The frequency's start offset, with its format	02:00 (absolute)
Late to Start Offset	The frequency's late-to-start offset	00:30
Estimated Run Time	The frequency's expected run time	12 min
Max Run Time	The frequency's run-time limit	60 min

A pool and a legacy agent group are labelled, an agent is not. The three dispatch differently, and a pool named PROD-POOL under a column headed Agent is otherwise indistinguishable from an agent of the same name — so only the bare name is an actual agent.

Start Offset carries its format because the number alone is ambiguous. An offset is a duration from the schedule date, so 02:00 means two hours in, not 2am — see offsets past midnight. A job whose configuration is missing the format shows the bare offset rather than asserting a base that was never stored.

The four timing columns return one row per frequency

Agent belongs to the job. The other four belong to a job frequency: a job on a Daily and a Month-End frequency has two start offsets and two run-time limits, and there is no single row they both fit on. So selecting any of the four expands the result to one row per (job, frequency).

Rows that differ only in timings read as corruption rather than as two schedules, so the frequency's name has to travel with them:

• Selecting a timing column also selects Frequency Name.
• Unselecting Frequency Name takes the four timing columns back off with it.
• A report definition that names a timing column without Frequency Name is refused with a message naming the missing column. The page never builds one, so this is only reachable by driving the API directly.

Agent does not trigger the expansion. Select it on its own and the report stays one row per job, with frequency names collapsed into a single cell as before.

note

The five columns sort but do not filter — there is no Agent or Max Run Time filter yet. They are also sorted over the fetched result rather than pushed to the server, and an export does not apply that sort: a report sorted by one of these downloads in job-name order. Workflow Version and Frequency Name already behaved this way.

Workflow Version now sorts as a number

It used to be compared as text, which ordered version 10 ahead of version 2. It is compared numerically now, so a Jobs report you already saved sorted by that column comes back in a different — and correct — order.

Job History: five columns from the instance itself

Job History gained Frequency, Tags, Documentation, Start Offset, and Latest Start Time.

Column	Filter operators	Notes
Frequency	Contains, Equals, Starts with	The frequency that triggered this instance.
Tags	Contains	The job's tags.
Documentation	Contains, Equals, Is empty, Is not empty	The job's documentation text.
Start Offset	Equals, Is empty, Is not empty	The configured start offset (HH:mm) for the triggering frequency. A job with no offset configured reads as empty, so Is empty is meaningful.
Latest Start Time	On, Before, After, Between	The latest allowed start time for the instance.

All five are build-time snapshots of the instance, not a live look-up. Each instance is built from exactly one matched frequency, so these report what that instance was built with — change the job's design tomorrow and yesterday's rows keep yesterday's values.

The frequency type filter also offers the two new periods, On Request and Annual Plan (see Frequencies).

Service Requests

A Service Requests report answers "what is published, who owns it, and how big is it" across every service request in the tenant. Every column is also a filter, and the same seven are offered in both roles.

Column	Filter operators	Notes
Name	Contains, Equals, Starts with	The request's name. All three operators ignore case.
Tags	Contains	The request's tags, joined for display.
Inputs	Equals, Greater than, Less than	How many inputs the request asks the requester for.
Events	Equals, Greater than, Less than	How many events the request fires when it is submitted.
Version	Equals, Greater than, Less than	The request's current version number.
Workspace	Contains, Equals, Starts with	The workspace the request is assigned to.
Last Updated	On, Before, After, Between	When the request was last modified.

Inputs and Events are counts, not lists — a request with no inputs reports 0. Use them to find the requests worth reviewing: a request with many inputs is the one a requester is most likely to get wrong, and a request with none runs on a single selection.

note

Filtering and sorting happen over the fetched result rather than being pushed to the server, except for Name (narrowed server-side first) and sorting by Name or Last Updated in an export. A very large tenant is better filtered down before sorting on Tags, Workspace, or one of the counts.

Roles

A Roles report answers "who can do what, and where" across every role in the tenant. It sits under its own Governance & access category. Every column is also a filter, and the same eleven are offered in both roles.

Column	Filter operators	Notes
Role Name	Contains, Equals, Starts with	The role's name.
Description	Contains, Equals, Starts with, Is empty, Is not empty	The role's description.
System Role	Is, Is not (Yes / No)	Built-in roles seeded by the platform. These cannot be edited or deleted.
Permission Count	Equals, Greater than, Less than	How many permissions the role grants.
Permissions	Contains only	The permission IDs, as objectType.action, joined with ; .
Scope Count	Equals, Greater than, Less than	How many workspace/environment pairs the role applies to.
Scopes	Contains only	Where the role applies, as Workspace / Environment pairs.
Created At / Updated At	On, Before, After, Between
Created By / Updated By	Contains, Equals, Starts with

Four things about it are worth knowing before you build one:

• Permissions can be longer than what was picked in the role editor. Granting any action other than view also grants that object type's view permission, and the report lists what the role actually holds. A role showing more permissions than you configured is not a fault.
• Any in a scope means unrestricted on that axis, not a missing value. A role scoped to one workspace and every environment reads Payroll / Any.
• Permissions and Scopes offer Contains and nothing else. Both filters compare against the whole joined cell, so Equals would match only a role whose entire list is the search term, and Starts with only one whose alphabetically first entry is. They are deliberately left out rather than offered as traps.
• The report describes what a role is configured to grant, which is now also what the services enforce — see Roles and permissions.
• Without workspaces.view, a report shows workspace ids where it would show names, and filtering or sorting it on the workspace name is refused outright rather than quietly matching nothing. This applies to the report's export as well as the report on screen.

note

Only Role Name is narrowed server-side; everything else — including all sorting — is applied over the fetched result. Roles arrive in name order, so a report you have not sorted is alphabetical by name. Filter a very large tenant down before sorting on Permissions or Scopes, which are sorted on their joined text.

Job History: Instance Name

Job History carries an Instance Name column and filter, reporting which named schedule instance the row's run belongs to.

Column	Filter operators	Notes
Instance Name	Contains, Equals, Starts with, Is empty, Is not empty	The schedule instance the job ran under. Empty for a workflow that does not build named instances, so Is empty selects exactly the single-instance rows — and is how you exclude them.

Workflow Name stays the bare workflow name in this report, not the composed Workflow_Instance form the Processes grids show. That column is also the report's Workflow Name filter, so a composed value copied out of a result and pasted back into the filter would match nothing. The instance is reported in its own column instead.

note

Instance Name sorts, but unlike the other columns it is sorted over the fetched result rather than pushed to the server, so sorting a very large result by it can differ from sorting by a server-side column. Filter it down first.

Building a report

Each report supports columns (selected and ordered), sort rules, and filters. Filter types:

Filter type	Operators
Text	Contains, Equals, Starts with, Is empty, Is not empty
Number	Equals, Greater than, Less than
Single-select	Is, Is not
Date/time	On, Before, After, Between

For example, Job History offers filters for environment (required), date range (required), workflow/job/agent name, termination status, exit code, run time, and duration.

The workflow, job and agent name filters take a * wildcard, the same way the Processes page's do: payroll* is starts-with, *payroll is ends-with, and a value with no * still matches anywhere in the name. ?, _ and % are all literal.

What a date filter matches

A date filter's controls take a date, while the values being matched are full timestamps. A date therefore means the whole UTC day it names — UTC because the report grid renders and labels its date columns in UTC, so the filter agrees with what you can see.

Operator	Matches
On	Anywhere within the named day.
Between	From the start of the from day through the end of the to day — inclusive at both ends.
Before	Strictly earlier than the named day. The day itself is excluded.
After	Strictly later than the named day. The day itself is excluded.

On, Before and After against one date therefore partition the timeline: a row satisfies exactly one of the three.

Two of these used to be wrong, and silently

On matched nothing at all — only a row stamped at exactly midnight could satisfy it — and Between dropped every row on the to day after midnight, which made "created today" inexpressible. Neither reported an error; the result set was simply short or empty and looked legitimate. If you built a report around either quirk, re-check it.

After changed too, and deliberately: it used to return rows from the named day itself and now excludes them. A saved report using After will return fewer rows than it did — use On as well if you meant to include the day.

Is empty and Is not empty

A text value can be blank in two ways — stored as an empty string, or never set at all — and the two are indistinguishable on screen. Is empty matches both, and Is not empty excludes both.

Three reports used to get this backwards

The Jobs report's Documentation filter and the Scripts and Roles reports' Description filters matched only the never-set form. Because almost every job created through the editor stores an empty string instead, Is empty returned close to nothing in an environment full of blank documentation, and Is not empty returned everything including the blanks. Both grid and export were affected, and both are now correct.

One related change: on those three filters, Contains or Equals with an empty value now matches every blank row rather than only the never-set ones. Contains and Equals with a real value are unaffected.

Column order and column selection stay in step. Checking a column adds it to the end of the column order, whether or not you open Sort Order. Earlier builds only recorded the order when that dialog was used, so a column you had checked could be missing from the order — and because results and exports follow the order, the column then appeared in neither. A report already saved in that state repairs itself when you open it: any checked column missing from the stored order is appended, so it renders and exports from then on.

Saved reports, results, and export

• A report can be saved (name, description, columns, column order, sort rules, filters) and re-run later. Saved reports are shared: everyone in your organization who can open Reports sees the same list, and each name can be used only once (ignoring case).
• The Reports page lists every saved report, grouped by report type and then object type, with no page limit. Earlier builds showed only the first 20 in name order and gave no indication the rest existed.
• Results are paginated (25 rows per page by default), with a truncation warning for large sets; large exports stream.
• Export formats: CSV and Excel (xlsx).

Good to know

• Reports are read-only — they don't change anything.
• A report saved against the withdrawn Audit History report can no longer be run. The saved definition is still listed, but the object it reported on is gone, so running or exporting it fails and it cannot be re-pointed at another object. Delete it.
• Known stub: the Agent Type filter currently has no options to choose from.
• Reports run on demand. There is no scheduled or emailed delivery of a report or of a saved search; run it and export the result when you need it.