Data apps: open, run, inspect and share

    A data app is a saved page that runs queries against your warehouse and renders the result. This guide is about reading one: finding it, re-running it, reading an older run, and saying exactly where a number on the page came from.

    What a data app is

    A data app is a dashboard, tracker, scorecard or report that someone saved so the rest of the team can open it. Behind it sits a workflow: the steps that fetch data, run SQL and render the output. You do not need to open the workflow to use the app, but it is what produces everything you see.

    Each execution is a run. Runs are kept, so last Monday's figures stay available exactly as they were on Monday. Opening an app does not re-run it, you land on the most recent run. Running it queries your warehouse as it stands right now.

    Find and open one

    1. Click Data Apps in the Build group of the left rail. The page lives at /data-apps.
    2. The page is headed Data Apps with a count beside it, and below that a grid of cards, one per app.
    3. Narrow the grid with the search box (Search data apps…) or the All / Favourites / Drafts pills. Group by folder switches between folder grouping and a flat grid; the same control reads Ungroup once grouping is on.
    4. Click a card. You land on that app's most recent run.

    Nearly every app works this way. A small number are persistent apps: they hold a standing list of cases people work through rather than a series of runs. Clicking one of those cards opens the cases view, there is no Run Now (the toolbar has Update Now instead, with a status beside it reading Updated 5m ago or Updating…), and there is no run selector until you switch to the runs view with the toolbar's view toggle. From there, everything below applies unchanged.

    Run Now and run history

    Use Run Now to query the data currently in your warehouse. A new run does not refresh the source data itself; check Connections or ask your admin when the source last synced. If the app takes parameters, a Run Parameters popover asks for them first. Rig selects the new run straight away and confirms with Data app started. The run happens in the background, so the page stays usable, and while it is queued or running a red Cancel button takes the place of Run Now.

    The run selector at the top of the page lists RECENT RUNS with a total count. Pick an earlier entry and the page re-renders with that run's numbers. This is how you answer "what did this say last week?" without rebuilding anything. A run you start joins the list as soon as you click Run Now.

    The Inspector

    The Inspector is a panel on a run that shows the machinery behind it. Which tabs appear depends on what the app does. Three matter to you as a reader:

    • SQL Queries: the queries that actually ran for this run.
    • Data: the rows those queries came back with.
    • Report: the rendered output you see on the page.

    The rest are there for whoever built the app: Raw JSON, State, Metrics, LLM Prompts, Template, Data Flow, Tables, Volume and Markdown. You can open them, but you do not need them to read a result.

    Trace a number to its SQL

    This is the single most useful thing the Inspector gives you, and it takes under a minute.

    1. Pick a figure on the page that you want to defend or question.
    2. Open SQL Queries and find the query that produced it. Note the tables it reads from.
    3. Open Data and find the matching row. Confirm it agrees with what the page shows.

    Figure, query, source table and row together make up the audit trail. When someone asks "where does this number come from?", you can answer with a table name and a query rather than forwarding the question to an engineer.

    Sharing

    Use Share. The dialog is headed Share Data App and has three tabs: People (who in the workspace can open it), Embed link (a public link you can put in another page) and Active shares (the links that exist, and how to revoke them). The button is shown to everyone, but each tab has its own rule about who can use it.

    People and general access

    Only the person who created the app can change who has access, and Rig can do it on their behalf. Role does not come into it, so a workspace owner who did not build the app is refused too, with Only the owner can change sharing. You can always share an app you built yourself, whatever your role.

    • Under People with access, enter a colleague's email, pick viewer, commenter or editor, and click Add. The person must already be in your workspace; any other address is refused with No user with that email in this workspace. All three options let the person open the app. Changing the app itself needs the editor role or above in the workspace, whichever option you pick.
    • To share with a group instead, use the picker underneath, Or a role, team or team leads…, which lists Roles, Teams and Leads of a team. Pick one, choose the same viewer, commenter or editor option and click Add.
    • General access sets who else can open the app from its link. The levels run from Restricted — only people with access through Workspace admins with the link, Your team — internal members with the link and Anyone in the workspace, incl. guests, with the link to Anyone with the link. Every level except Restricted also takes a role.

    New apps start as Restricted. Until the creator first changes something in this dialog, anyone whose role can read the data the app uses can still open it, though some apps are limited to editors and owners until then. After the first change, Restricted means only the creator and the people listed.

    Sharing an app does not share the data behind it. If someone's role cannot read the tables the app uses, they can still see the app, but its runs show You don't have permission to view this report and they cannot run it. An owner fixes that by granting their role access to the data. Runs you share with a person are the exception, as Which runs people see explains.

    Which runs people see

    When you add a person, or an agent from the picker underneath, Runs people and agents see sets which runs they can open. The runs are shared on your access, so they can open them even if their own role cannot read the app's data, and Rig checks your access again whenever they open one. They still cannot run the app that way. A share with a role, a team or the leads of a team takes no run scope: those people get the app only, and see its runs only if their own role can read the data.

    • This run shares the run you have open. If that run has not completed, the option reads Latest completed run (date) and shares that run instead. Sharing a run again with the same person adds it to the runs they already have, up to 100 shared one by one.
    • This run + past runs shares that run and every completed run before it. Later runs are not included.
    • All runs (incl. future) shares every run of the app, including the ones it has not made yet, which is what a scheduled report needs. A step that failed shows only This step failed., without the error text.
    • App only (no runs) shares the app without runs. Picking it for someone who had runs shared before takes those runs away.

    The picker starts on This run when the app has a completed run. When it has none, a line under the picker reads This app has no completed run yet: share all runs (including future ones), or the app only. and the picker shows Keep their current runs access until you choose: someone already shared runs keeps them, and someone new gets the app only. If the app's runs cannot be shared at all, only App only (no runs) can be picked and the line says why, for example This app is personalized per viewer, so its runs can't be shared. In the list of people with access, each person's line shows what they have, such as 1 run · 10 Oct, Runs up to 10 Oct or All runs.

    If your own access rules narrow what this app reads, its runs are private to each viewer and only This run, on a run you started yourself, can be shared. The wider options fail with Couldn't share these runs and Your access rules narrow this Data App's results, so its runs are private to each viewer. Only a run you triggered yourself can be shared, one run at a time. The message offers Share without these runs, which shares the app on its own and leaves any runs they could already see unchanged.

    A shared run can open with This run's output isn't included in what was shared with you. and Ask the app's owner to share it. in place of the report. Rig shares only what the app's run page displays. When it cannot work out how this app displays its runs, or the run holds nothing it can show that way, none of the run's output is shared.

    Embed links

    An embed link opens the app without a Rig login, so anyone who has it can view. To make one you need a role that is allowed to create external shares, and external sharing has to be switched on for the workspace. Otherwise the tab shows a message instead of the form. While sharing is off for the workspace, whatever your role, it reads External sharing is disabled for this workspace. Ask an admin to enable it. Once it is on, a role without the permission sees Your role doesn't have permission to create external shares. You do not have to be the app's creator, but Rig refuses the link if the run reads a schema your role cannot read, and refuses Always show latest successful run when your access rules narrow what the app returns, as Links that open the latest run explains.

    1. Under What to share, keep Always show latest successful run (default) so the embed updates every time the app runs, or choose Just this run for a frozen snapshot, such as a board pre-read.
    2. Pick when it Expires: 1 day, 30 days, 90 days (default), 1 year, or Custom... for any whole number of days from 1 to 3653.
    3. Click Create share link and copy the Embed URL. From there, Extend under Extend expiry pushes the date out, and Revoke ends the link.

    To put it in Notion, type /embed on the page and paste the URL. Notion embeds have a fixed height, so drag the bottom-right corner to resize it. An app that shows each viewer their own rows cannot go in a public embed link, because a public link has no viewer to scope it to. To embed one where each viewer is signed in, see Embed a Rig data app in Salesforce.

    Active shares lists the links you created, and owners see everyone's, each with Extend to 90d and Revoke. The same list across all your apps is under Settings → Sharing → Active Shares.

    So if you are looking at an app someone else built and want a colleague added, ask its creator to do it from their People tab.

    Download and export

    • Download PDF saves the run as a PDF. On an interactive dashboard it keeps the filters and tab you have selected; a report is saved in its default state.
    • Export CSV downloads the rows a data step returned. When more than one step returned rows, it becomes a menu with one entry per step, named by its step ID and row count, such as data_1 (1,234 rows). If no step returned rows, there is no button. A run keeps only a capped number of rows per step, so a large step can export fewer rows than it returned. When that happens Rig says Export truncated and Exported first N of M rows — the stored run output is capped.

    Scheduling

    An app can run on a clock, but that is set up deliberately by whoever built it. You cannot tell from the grid card whether an app is scheduled, and the card does not show a schedule. If you need to know when an app last refreshed, read the run selector; if you need to know when it next will, ask the person who built it.

    Common problems

    For a run that failed, with a red Run Failed panel in place of the report, see When a data app run fails.

    • You get "Run already in progress". Another run of the app is still going, perhaps one a colleague started. Wait for it to finish, which can take minutes for a long query, then run again. On an app that shows each viewer their own rows there is no pop-up: a grey note reads Another refresh is in progress — this app updates per viewer, and Rig tries your refresh again once that run has finished.
    • The app shows old numbers. You are looking at a saved run. Check the run selector and re-run to query the warehouse again. If the numbers are still old, check when the source last synced or ask your admin.
    • It says there are no runs yet. The app has been created but never executed. Run it once.
    • The numbers do not match your old system. A data app reads live warehouse data, which is not the same thing as a validated, signed-off figure. Report the difference rather than assuming either side is wrong.
    • You cannot see an app a colleague mentions. Data apps respect access. If the app has never been shared, whether you see it depends on your role being able to read the data it uses, so an owner can fix it by granting your role that data. Otherwise ask the person who built it to share it from the People tab; only they can change its sharing. Apps Rig built for you have no creator in your workspace, so ask Rig to share those.
    • You get "Only the owner can change sharing". You opened Share on someone else's app. The button is shown to everyone; the grant is not.
    • Create share link fails with "Your access rules narrow this data app's results". Your role's rules filter or mask something this app reads, so an embed that always shows the latest run is refused. Use Just this run on a run you started, or share from the People tab, as Links that open the latest run describes.
    • An embed link now says "This data app's runs are private to each viewer and cannot be embedded". Something changed after the link was made (the access rules, the app's queries or the run it shows), and the rules of the person who created it now narrow the app. Replace it with a Just this run link or a People tab share.

    Was this guide helpful?