Dashboard

The dashboard, at ontyx.io/dashboard, is where you see what your organization keeps in Ontyx, say yes or no to what your assistant proposed, and manage who has access. Data is set up and asked in conversation; the dashboard shows it and decides on it, and never edits a proposal. To change something an assistant proposed, reject it with a reason and ask again.

Everyone in the organization can open the dashboard. What they can change depends on their role (see Roles).

Overview

The first page shows what’s waiting for approval, how many people are in your organization and how many API keys are active (owners and admins), each a shortcut to its page, and your plan in one line that links to Billing.

Datasets

Every dataset your organization keeps, with:

• how many rows it has, the date its data is as of, and whether it’s up to date (and what that means for its schedule);
• how new data is added (replaced, added to, or updated and added to);
• how its last load went, in one sentence: what landed and what was checked, or why it was refused and that nothing was loaded;
• badges for what needs attention: a change waiting for approval, data out of date, marked for deletion, built from other datasets.

Open a dataset to see more, in this order:

• The facts: rows, as-of date, whether it’s up to date, and its data version and structure version.
• A change waiting for approval, in plain words, with who proposed it (only when there is one).
• Lineage: what the dataset depends on and what depends on it, as a graph (see Lineage).
• Columns: each column, the kind of value it holds, whether it’s always filled in, its meaning, and which columns identify each row.
• Checks, each with whether it passed on the last load.
• Points at other datasets: each relationship with how many rows match, and which datasets point at this one.
• Built from, for a dataset built from other datasets: its question in words, and the data versions of what it was built from.
• Last load in full: when, how it came in and who sent it, and every check it ran or the reasons it was refused.
• History: a small chart of the rows after each load, then every load (data version, when, how it came in and by whom, rows), and every structure version with who proposed it, who approved or turned it down, and what it changed. Point at the chart (or step through it with the arrow keys) to see one load: its rows, and for a load that adds or updates, how many rows it added.
• Preview, closed until you open it: the first 10 rows of the data version in use, the same rows your assistant’s preview gives, with Show 25 and Show 100 for more, each column’s kind of value, and a collapsed “What each column holds” list (blanks, smallest and largest values, about how many different values). A note says when the last load was refused, a structure change is waiting, the dataset is built from other datasets, or it’s marked for deletion. To filter or total the rows, or to see more than 100, ask your assistant.

The Datasets pages only show. Loading, changing a structure and deleting happen through your assistant.

Approvals

Everything your assistants proposed that’s waiting for an owner’s or admin’s yes or no:

• New datasets, with their structure read back in plain words.
• Datasets built from other datasets, with their question in words. Approving one builds it.
• Changes to datasets, listing what each one changes and any warnings.
• Metrics, new ones and new versions, each with the sentence that says exactly what it counts.

Each shows who proposed it and when. Approve does exactly what saying yes in the conversation does, with the same checks first. Reject asks for a reason, which is kept with the proposal so your assistant can read it when it proposes again.

When approving a change would stop approved metrics from working, the page lists them: tick each one to retire it with the change, then approve. When it would stop a dataset built from this one, the page says so, and that dataset has to be deleted first.

Readers can see what’s waiting but can’t approve or reject.

Metrics

The numbers your organization agreed on, with In use, Retired and All tabs. Each shows its sentence, the dataset it’s counted from and its version in force.

Open a metric to see what it counts (the sentence and your description), what it reads (each dataset and column, flagged if the dataset’s structure changed since it was approved), its Lineage graph, how to ask for it, and every version with who proposed and decided it, and why a rejected one was turned down.

An owner or admin can retire a metric here, with an optional reason. A retired metric can’t be asked any more; it stays under the retired tab with every version, and approving a new version brings it back.

Views

Your organization’s saved views. Each shows its name, description, the sentence saying what it asks, the metrics it reads (with the version in use now, and a note when a metric has a newer version than the one the view was saved with), what’s filled in each time it’s asked, and who saved it. Each card also has a Lineage row that opens the view’s Lineage graph.

An owner or admin can rename a view (every assistant then asks it by the new name) or delete it (its metrics and their data stay). What a view asks is changed by asking your assistant to save it again.

Lineage

The dataset page, the metric page and each view card show a Lineage graph, read left to right: what the dataset, metric or view depends on is on the left, and what depends on it is on the right, however far back or forward the links go. Each arrow runs from an item to what uses it:

• from a dataset to another dataset whose rows point at its rows;
• from a dataset to a dataset built from it;
• from a dataset to a metric that reads its columns;
• from a metric to a view that uses it.

So a dataset you load has arrows leaving it, and none arriving unless its rows point at another dataset’s rows.

A link that is behind is dashed and marked: a view saved with an older version of a metric than the one in use, a dataset built from a source that has newer data since its last build, or a relationship whose last check found rows pointing at rows that aren’t there. A metric that’s been retired shows its link to a view as stopped: the view leaves it out. Pointing at a link (or tabbing to it) shows what it means and why it’s behind, under the graph, where the links that are behind are also listed. Select a box to open that dataset’s, metric’s or view’s page.

The graph is drawn from what Ontyx recorded about your data, never from its rows, and changes nothing. Your assistant can give the same picture in words: see Lineage and history.

Members

Everyone in the organization, with their role and when they joined.

Owners and admins can:

• Invite someone by email, as an admin or a reader. Ontyx emails them an invitation, and the link signs them up. Someone who already has an Ontyx account gets no email: they join the next time they sign in.
• Change a member’s role between admin and reader.
• Remove a member. Their assistant loses access on its next request.
• Revoke an invitation that’s still waiting.

Nobody can change or remove the owner, and nobody can be made owner. A person belongs to one organization: an email that already belongs to another organization, or already has an invitation waiting, can’t be invited.

Readers see the members list, but not invitations.

API keys

The keys your scripts use to send data through the Push API. Owners and admins can see, create and revoke them; readers can’t see them.

• Create a key with a name of up to 64 characters. Name it after the script or job that will use it, so you know which one to revoke later. The key is shown once: copy it then.
• A key can only add data to your organization’s datasets. It can’t read anything, and it can’t be used to connect an assistant.
• Revoke a key and it stops working straight away. Any script still using it is refused. Revoked keys stay listed with when they were revoked.

Each load a key sends is recorded as pushed by that key, by its name. See Lineage and history.

Organization

Your organization’s name, your role, and the connector address to add to your assistant, with a copy button and a link to Connect your assistant. Owners and admins can rename the organization.

Roles