Test Data

Owners can populate an organization with synthetic demo data from Settings → General → Generate test data. It is the quickest way to see a fully populated ActivityPulse — dashboards, org chart, summaries, value stream, red flags — without connecting a single real system.

Nothing in the generated data comes from a real person, project, or system. The people, projects, issues, and conversations are all invented, and the email addresses use a reserved example domain.

What the toggle does

While Generate test data is on, every data source generates synthetic activity on its normal sync schedule instead of contacting the live system it is configured for. No credentials are used, and no requests leave your deployment.

Turning it on immediately:

  • Creates the demo teammates, with their reporting lines and teams.
  • Enables a data source for each supported system, marked as test data.
  • Starts a first sync straight away, so data appears within seconds rather than at the next scheduled sync.

The first sync backfills the whole sync window (see Settings → Data Sync), so the organization looks lived-in right away. After that, each scheduled sync adds roughly another day of activity, exactly as a real organization would.

What gets created

A fictional software company of around a dozen people:

  • A manager, who runs one-to-ones and is meeting-heavy roughly one week in four.
  • Three engineering teams, each with a lead, developers, and QA. Each team uses a different toolchain, so several systems are populated at once.
  • A technical writer, who publishes documentation across the teams.
  • A sales team, working opportunities, leads, and cases.

Each team runs two or three projects at a time, and every project moves through a full delivery lifecycle — inception, planning, design, implementation, QA, and completion — with the meetings, documents, and conversations that go with each stage. Because the projects are staggered, any window you look at shows a believable mix: one project mid-implementation, another still in planning, a third wrapping up.

The work is correlated across systems, the way it would be in a real organization. An issue in one system corresponds to a branch in another, and the commits and merge requests on that branch reference the issue. Summaries, goal assignments, and value stream analytics therefore join the data up exactly as they do for real activity.

Every organization gets its own distinct set of people and projects, and the same organization always regenerates the same history.

Summaries in demo mode

Summaries are pre-populated for you. A demo organization fills its Summaries page automatically — one summary per person and one per team for each completed week — a few minutes after the data finishes generating, and keeps them current as new weeks complete. You do not need a language model: demo summaries are written from the generated activity by a built-in template, not an LLM.

Generate Summary works the same way. Pressing it on a demo organization produces a summary right away, with no provider configured and without spending any API credits. Custom instructions are ignored in demo mode — the template does not take free-text guidance.

The one thing that still needs a provider is the Value Stream Analyze with AI button. That analysis is written live by a language model, so on a demo organization it stays unavailable until you add a provider under Settings → LLM Configuration, exactly as it would on a real organization. Adding a provider does not change how demo summaries are written — they remain template-generated and never call the model.

The demo keeps office hours

Generated activity follows a normal working rhythm: it lands on weekdays, during business hours, the way a real team’s would. There is no weekend or overnight work in the data.

One consequence is worth knowing. If you open a demo organization on a weekend, its freshest activity is the last business day — nothing is dated to the weekend itself. This is expected, not a gap.

Red flags in the demo

The demo organization is provisioned with red-flag thresholds tuned to the size of the generated team, so the Red Flags page has something to show — an overloaded developer, a meeting-heavy manager, a chronically late meeting joiner, a forgotten backlog issue, and more.

Those thresholds are visible under Settings → Red Flag Thresholds, and you can adjust them there exactly as you would for any organization. They are ordinary settings, not something special to the demo.

Issue Hierarchy and Value Stream

Both Issue Hierarchy and Value Stream Analytics work on a demo organization, for every provider that offers them — GitLab, GitHub, Jira, and Azure DevOps. There is nothing extra to switch on.

The pages load themselves

Opening an Issue Hierarchy page or the Value Stream workbench on a demo organization loads the first available project straight away. You do not have to type a query or press Load to see something.

On the GitHub Value Stream the automatic load brings up the first repository with a sample of its issues rather than all of them, because that stream works from an explicit list of issues. It is a starting point, not the whole repository — add or change issues in the query to look at the rest.

If a project is already named in the address — following a link someone shared with you, or a bookmark — that choice is always honored, and never replaced by the automatic one.

Queries and filters are ignored

On a demo organization the search box is inert. Whatever you type, you get the complete tree of the selected project back:

  • Jira — the JQL query is ignored.
  • Azure DevOps — your filter is ignored.
  • GitHub — search qualifiers are ignored.
  • GitLab — the milestone, label, and state filters are ignored.

This is a property of the generated data rather than of the query language: there is no live system behind the page to run the query against, so the whole project is returned every time. On an organization connected to a real system, all of these work normally.

The demo organization’s projects live at addresses that are deliberately fictional — an invented GitLab host, an invented Jira site, and an invented GitHub host. Every one of them uses a reserved .example name that can never be registered by anyone, so a demo link cannot lead to real content, and cannot start doing so later. Issue and merge request links are built exactly as they would be for a real system, so they look right, but there is nothing at the other end. They are not meant to be followed.

Older issues show less of their history

On the Jira and Azure DevOps pages, an issue that has been around for a while can show its full issue history — created, assigned, status changes, comments — alongside only a few commits or merge requests, or none at all.

Nothing is missing. The issue side of the timeline covers the issue’s whole life, while development events only exist for the period the organization has actually synced. An issue whose coding happened before that window shows the same gap in a real organization — this is that behavior, not a quirk of the generated data. Widening the sync window (Settings → Data Sync) and letting the next sync run fills more of it in.

GitLab goes further: on the GitLab Value Stream, an older issue can show an empty timeline rather than a partial one. Its whole timeline — the issue events as well as the commits and merge requests — comes from what has been synced, so an issue whose activity falls entirely before the sync window has nothing to show. The issue still appears in the tree, and widening the window brings its timeline back. This is the same behavior a real GitLab organization shows.

GitHub is unaffected: its timelines are complete however narrow the sync window is.

Only on an empty organization

Generate test data can only be switched on while the organization has not collected any activity or signals yet. If it holds either, enabling is refused with:

Test data generation can be only enabled on an empty database

This is what keeps generated and real data apart. Nothing distinguishes the two once they are stored — a generated teammate looks like any other teammate, and a generated commit looks like any other commit — so the only reliable moment to separate them is before the first generated row exists.

Create a new organization for demos. An organization that has already synced a real system cannot be used for test data.

It cannot be turned off

Enabling is permanent for that organization. Once Generate test data is on, the switch locks and generation cannot be stopped — for the same reason it cannot be turned on late: the generated data is already indistinguishable from real data, so an organization that has generated once can never safely sync a live system again.

You are asked to confirm before it is switched on. If you no longer want the demo organization, delete the organization itself.

What demo mode does not create

Test data fills the product with teammates, activity, and signals — but it does not create user accounts. The Users page still shows only the real people you have invited. Generated teammates are the subjects of the activity, not people who can sign in.

This matters for one thing in particular: seeing the product the way a manager does. To try the manager experience — My Direct Reports and the manager default filter — set it up yourself:

  1. Create a user and give them the Manager role.
  2. On the People page, link that user to the demo organization’s manager teammate.
  3. Sign in as that user.

You will then see the demo manager’s reports and the manager-scoped views, driven by the generated org chart.

Notes

  • The toggle is visible to Owners only.
  • It affects one organization. Other organizations are unaffected.
  • Any data source holding a real configuration is left exactly as it was — its credentials are never touched.
  • A data source that holds a real configuration but is currently disabled stays disabled, and generates nothing until you enable it.
  • Generated data sources show as valid without a configuration — there is nothing to validate, because no live system is contacted.