Artifact sources

Artifact sources let you bring outside data into Admire, from tools like your CRM, support desk, or any system that produces records. Once your data is in, you can query it and surface it in dashboards and role metrics, connecting what people do to the outcomes it produces.

Why bring data here rather than into a BI tool or a spreadsheet? Artifact sources sit right next to your people and skills and are built to be simple: you get an easy way to combine data from several systems without standing up a complex BI stack, and Admire’s permissions are preserved, so each person sees only what they’re allowed to. Performance data lands in context, where it drives coaching and lets individuals monitor their own results.

Each artifact source is a kind of record you track, with its row count and type at a glance.

Use cases

• Let individuals self-monitor: ingest the data tied to a role (a rep’s deals, a support agent’s tickets) so each person can see their own performance on their profile and power role metrics that update continuously.
• Combine data without a BI project: pull records from several systems into one place and join or aggregate them with derived sources and queries, with no separate warehouse or BI tool to stand up and maintain.
• Permission-aware reporting: because access follows Admire’s existing permissions, you can share dashboards and metrics broadly, knowing each person only ever sees the data they should.

Data from your operational systems lands in Admire and becomes the performance insights and KPIs your team coaches against:

flowchart LR
  subgraph Sources["Your operational systems"]
    CRM["CRM<br/><small>deals, pipeline</small>"]
    Desk["Support desk<br/><small>tickets</small>"]
    Dev["Dev and ops tools<br/><small>PRs, calls, usage</small>"]
  end
  AS(["Artifact sources<br/><small>in Admire</small>"])
  subgraph Out["Performance in context"]
    M["Role metrics and KPIs"]
    D["Dashboards"]
    P["Self-monitoring on profiles"]
  end
  CRM --> AS
  Desk --> AS
  Dev --> AS
  AS --> M
  AS --> D
  AS --> P

What a source is

A source is a definition of a kind of data you want to track. Each source has columns with types (text, number, date, true/false, and so on). Admire works out a new column’s type from the first data that contains it, so you don’t have to set up columns up front. It doesn’t change that type later: if later data doesn’t fit, change the column’s type on the Columns tab. Values that don’t fit read as empty.

One type is never inferred for you: User. Set a column’s type to User when its values are the IDs Admire uses for people, and the records grid renders each value as that person, linked to their profile, rather than as a bare number. A value matching nobody in your organization shows as “Unknown user” alongside the ID, so a bad mapping is visible at a glance. Queries, dashboards, and role metrics still read the plain ID, so a User column is what a metric’s :staff_id filter compares against.

Records of any shape

A record can be any JSON shape, and Admire adds a column for the fields it finds. Each column routes a JSON path to the value it shows, so you can add a column that pulls from a nested field, not just a top-level one.

For example, given a record like:

{ "number": 42, "state": "open", "author": { "login": "alice" } }

you might define columns that route to:

• pr_number → $.number
• state → $.state
• author → $.author.login

The JSON stays as-is; the columns decide which paths become tidy, typed columns for querying and reporting.

Getting data in

See Uploading & ingesting data.

Artifact processing (dynamic columns)

Beyond the columns that come straight from your data, you can add dynamic columns computed with SQL, for example a derived status, a bucket, or a score. The processing runs over the source and stores the results as extra columns you can query and report on just like any other. See Querying your data (SQL) for how the queries work.

Derived artifact sources

You can also create a derived source: a brand-new source whose rows are produced by a SQL query over one or more existing sources. This is the way to build aggregations, cross-source joins, or computed tables that you then query and chart like any other source.

When you create a source, turn on Derived and supply the query whose result becomes the new source’s records. You can write it in plain English or in SQL (see Querying your data).

A derived source: the result of its query (here written in plain English) populates the new source as its records.

A derived source pulls from one or more existing sources, runs your query, and saves the result as a new source you can query:

flowchart LR
  S1["Deals<br/><small>source</small>"]
  S2["Tickets<br/><small>source</small>"]
  Q{{"SQL query<br/><small>join · aggregate</small>"}}
  N(["Rep performance<br/><small>derived source</small>"])
  S1 --> Q
  S2 --> Q
  Q --> N

Sharing a source

Admins, Coaches, and Coachees can create a source, in the app or through a connected AI tool, and whoever creates one owns it: it is theirs and an Admin’s until they share it. To give one person, team, or role access to just this source, use its Permissions tab. The creator’s row there, at Full access, is the access creating the source gave them, and it changes like any other row: removing it takes the source away from them unless a team, a role, or their permission set also gives them access. See Sharing sources & dashboards.

Purging vs. deleting

There are two ways to clear data, with an important difference:

• Purge removes the records in a source but keeps the source itself. Its columns and configuration stay in place, ready for a fresh load. Use this to reset the data without rebuilding the source.
• Delete removes the entire source, its definition and all its records. Use this when you no longer need the source at all.