# Apps (/docs/overview/apps)



An **app** is a self-contained home for one analysis. It holds everything that
analysis needs in one place: its data, the logic that shapes that data, and the
**Visualisation** your team works in. Because each app is self-contained, you can
build, share, and change one without touching any of the others.

You manage all of your apps from the **Apps** page in the left navigation.

## The two kinds of app [#the-two-kinds-of-app]

Ovidens has two kinds of app, and you pick the kind that matches what you are
trying to do.

* An **analytic app** is for combining data intelligently. Use it when your answer
  comes from bringing several sources together, cleaning them, and reshaping them,
  for example joining a sales export with a list of regions and presenting revenue
  by region.
* An **indicator app** is for collecting key figures over time. Use it when you
  record values by hand, period by period, and the data is multidimensional, such
  as monthly fuel use per site or quarterly headcount per team, and want Ovidens
  to compute totals, ratios, and trends for you.

If you are unsure, ask which sentence fits better: "I need to combine and reshape
data into a report" points to an analytic app, while "I need to record figures by
hand every period and watch how they move" points to an indicator app.

## The app and its editor [#the-app-and-its-editor]

Every app has two faces, and one button moves you between them.

* The **app** itself is what everyone opens: the finished Visualisation with the
  data in it, and none of the building controls. This is what your teammates see.
* The **editor** is where you build it: the data pipeline, the Knowledge Base, and
  the Visualisation you are assembling.

To go from the app to the editor, click **Open editor** in the top right, or press
<kbd>E</kbd>. To go back, point at the app icon in the top left of the editor bar
(it turns into a **Back to viewer** arrow) and click it, or press <kbd>E</kbd>
again. See [Keyboard shortcuts](../tips/keyboard-shortcuts.mdx).

## Draft and publish [#draft-and-publish]

Everything you change in the editor goes into your **draft**. A draft is private:
it is saved for you continuously as you work, and nobody else sees any of it. The
editor bar says &#x2A;*Draft (private)** while you have one, and spells out why:

> Only you can see this draft. Viewers keep seeing the published version.

That includes running an analytic app. Running is a private preview of your draft,
not a release: your teammates keep seeing the last published results until you say
otherwise.

When you are happy, click **Publish**. Ovidens asks you to confirm, lets you give
the version an optional name (something like "Q3 metrics" is enough), and warns you
that your viewers will now see these changes. For an analytic app the dialog also
offers **Publish and run**, which publishes and then immediately runs the pipeline,
so viewers get the new logic and fresh results in one step.

Each publish creates a **version**: a snapshot of the whole app at that moment.
Versions are kept in order under **History**, the clock button in the editor bar,
so you can look back at how the app used to be.

Two more controls sit next to the draft:

* **Discard** throws the draft away and brings back the last published state. If
  you also entered data while the draft was open, that data goes back to the
  published data as well.
* **Restore**, on any older version in the history, brings that version back and
  publishes it as the newest one. It restores the data of that version too, so any
  data entered since that version was published is replaced. Ovidens tells you this
  in the confirmation before anything happens. Before it moves anything, Ovidens
  makes a safety copy of the current state as an automatic version, so the data you
  entered since the last publish is still in the history afterwards. If your
  workspace has reached its limit on versions per app, that copy cannot be made -
  and rather than replace data it could not keep, Ovidens refuses the restore and
  says so. Ask a workspace administrator to raise the limit.

  In an analytics app, a restore then recalculates the app automatically: the editor
  shows the run in progress and, without a reload, the restored results when it
  finishes - or, if the restored version cannot be calculated, which node failed,
  with a link to that node and a **Re-run** once you have fixed it. A restore is
  refused while a pipeline run is in progress; wait for the run to finish, then
  restore. Restoring is for workspace administrators, so the control is shown only
  to them.

<Callout type="info">
  While an app has an open draft, data entry in the app is paused for everyone else:
  "This app is being edited. Data editing is locked while the draft is open - you
  are seeing the latest published data." Publish or discard the draft to release it.
</Callout>

## Who builds and publishes [#who-builds-and-publishes]

Building apps is for members who hold the **App builder** or **Admin** role. With
the role on the whole workspace, either can create an app, edit its details, put the
apps of a shared space in order, and archive and restore apps. In an analytic app they can
also change everything in the editor - the pipeline, the Knowledge Base, skills and
the Visualisation - and publish, discard the draft, and restore an older version.
Removing a Knowledge Base page for good, from its trash, stays with administrators.
In an indicator app they can build the structure - indicators, groups, dimensions,
the reporting-unit dimension and consistency checks - and in a survey app the form,
its questions, the collection settings and the share link; in both they can publish,
discard the draft and restore an older version. Running data collection in an
indicator app - collection rounds, reporting periods and their sign-off, and the
reporting interval - is for administrators and for **reporting managers**, a role an
administrator gives on a space or an app; the indicator AI assistant stays with administrators.

Everyone else opens the published app and works with its data. Ovidens shows them
only the controls they can use: the **Apps** page has no create, reorder or archive
controls in a shared space for them, and in the editor the app's configuration is
read-only while entering data still works. Everyone keeps their own favourites, puts
the spaces in their own order, and orders the apps in **My space**.

## Create and open an app [#create-and-open-an-app]

Vera can create a fully built app for you from a plain-language description. See
[Build with Vera](../analytical-apps/build-with-vera.mdx) for the analytic path
and [Build with Vera](../indicator-apps/build-with-vera.mdx) for indicators.

To create one yourself:

1. Open the **Apps** page from the left navigation.
2. Choose **New app** at the top right and pick the space the app should go into under
   **Create in*&#x2A; - or select the &#x2A;*+** on that space's own header - then pick the kind you
   want. In **My space** only you can see it; in a shared space everyone with access to that
   space can. Only the spaces where you are allowed to create apps are offered. (In a
   workspace with no apps yet, the welcome screen's create cards put the app into
   **My space**.)
3. Give it a name (and an optional description so teammates know what it is for). The
   dialog shows which space the app goes into.
4. Confirm to create it.

Your new app appears in its space's group on the **Apps** page. Click its row to open it and
start building.

### Spaces [#spaces]

The **Apps** page groups your apps by **space**:

* **My space** comes first. Every member has one, and every member can create apps in it,
  whatever else they may do in the workspace. Nobody else sees the apps in it - not a
  colleague, and not a workspace admin.
* Below it are the shared spaces you can reach, such as **Workspace**, the space every
  workspace starts with. A shared space you cannot reach is not shown at all.

**New app** at the top right asks which space an app goes into, and so does the import button
(**Import an app file*&#x2A;) unless only one space is shown, because the space decides who can open it; each space's header also carries its own &#x2A;*+** and import button,
wherever you are allowed to create or import apps in that space. Use **Spaces** to show only some
of your spaces. If there is no space you may create apps in, or your spaces could not be loaded,
the page says so.

Admins create, rename and delete shared spaces on the **Access** page - see
[Roles and spaces](../administration/index.mdx#roles-and-spaces).

An indicator app in **My space** collects figures from you alone: you can enter values
into it, but it cannot run a collection round, because nobody you asked could see the app.

### Stars and the order of your page [#stars-and-the-order-of-your-page]

* **Stars.** Point at any app you can open and select the star (**Star**). A starred app
  carries a small star on its icon, and **Starred only** narrows the page to your starred
  apps. Stars are yours alone: a colleague sees their own, never yours, and a star changes
  nothing about the app. Select the star again to remove it.
* **The order of the spaces is yours.** Choose **Move up** or **Move down** in a space's ⋮
  menu (or the space header's own arrow button, when that is the only thing you can do with
  the space). The order is kept for you alone; a space you have never moved keeps its place
  after the ones you arranged.
* **The order of the apps in a space** follows the column you sort by: click a column
  header to sort by it. The page opens on **Last opened**, newest first.

### Move an app to another space [#move-an-app-to-another-space]

Moving an app is how you share it: an app you built in **My space** reaches your colleagues
once you move it into a shared space. Choose **Move to another space** in the app's ⋮ menu on
the **Apps** page (or the row's own folder-with-arrow button, when moving is the only thing you
can do with the app), then pick where it goes. You can also drag the app onto another space's
group: the spaces it may move into are highlighted, and releasing it there opens the same
dialog.

Moving an app changes who can open it, so before anything is saved the dialog tells you the
effect as numbers - for example "12 people lose access" and "30 people gain access". When other
apps import this one, it also says how many of the people who build those apps could no longer
change them after the move, because they would no longer be able to read this app where it goes.
It never names anybody, and it never counts an app in somebody else's personal space: if one
of those stands in the way, it says only "An app you cannot see imports this one". Nothing moves until you select **Move**, and every move is recorded.

You can move an app:

* out of **My space** into any shared space where you are allowed to create apps;
* from one shared space into another where you are allowed to create apps, if you may
  change the app;
* into **My space** only if you are a workspace admin, because that takes the app away from
  everyone else. Somebody else's space is never offered.

The dialog also tells you when a move is not possible, and why:

* An app moving into **My space** cannot take a collection round with it, nor a role
  given on the app itself (remove the role on the **Access** page first).
* An app in **My space** can be imported only by other apps in **My space**, the same rule
  that applies when you add an import node. So moving an app into **My space** is refused
  while an app outside it imports it, and moving an app out of **My space** is refused while
  it imports an app that stays behind there. Imports from shared apps you can read are
  allowed wherever the app goes.

### See which apps import an app [#see-which-apps-import-an-app]

An app can be imported by other apps (see [Analytic app data](../analytical-apps/pipeline/analytic-data.mdx)).
Everybody who can read an importing app sees what it imports, so the apps importing yours are part
of who can see its data. The **Imported by** column of the **Apps** page counts them; click the
count to list them in the app's settings. You see by name the importing apps you can open yourself; a workspace admin
is also told how many other apps in shared spaces import it. An app in somebody else's personal space
is never named or counted, and nobody else is told anything about apps they cannot open.

## Leaving an app [#leaving-an-app]

Getting back to the **Apps** page catches people out, because there is no separate
Back button. The app's own **name**, at the top of the left navigation, is the
control: point at it and it turns into a **back arrow**. Click it and you are back
on the **Apps** page.

It is the same in every app, analytic and indicator alike, so it is worth learning
once. (Inside the **editor** the same idea applies one level down: the app icon in
the top left of the editor bar turns into **Back to viewer**.)

If you would rather be shown than told, the app can walk you through it:
[take the tour of going back](https://app.ovidens.com/apps?tour=back-to-apps). The
tour runs on a practice app, so nothing you click during it touches your own work.

## Archive and restore an app [#archive-and-restore-an-app]

Nothing you remove from the **Apps** page is thrown away immediately. Choosing
**Archive** in an app's ⋮ menu (or the row's own archive button, when archiving is the only
thing you can do with the app) opens **Archive Analytic App**, which explains what really
happens:

> The app will be archived and removed from your workspace. Its data is kept during
> the recovery window, and you can restore it from Archived apps until it is
> permanently deleted.

An archived app disappears from the Apps page and stops counting towards the number
of apps your workspace is allowed, so archiving one immediately frees a slot for a
new app.

Members with the **App builder** or **Admin** role on the whole workspace get an
**Archived** button in the Apps page header, with the number
of archived apps on it. It opens a list where each app shows **Archived** on a date,
**Will be permanently deleted** on a date, and a **Restore** button. Restore brings
the app back to the Apps page exactly as it was, and takes its app slot back, so it
can fail if your workspace is at its app limit.

The recovery window is a workspace setting (30 days unless your administrator has
changed it). Once it passes, the app and its data are permanently removed and cannot
be recovered. Its technical id is not freed: no new app in the workspace can take it,
so an app that imported data from the deleted one can never start reading a different
app under the same id.

## Export and import an app [#export-and-import-an-app]

An app can be moved between workspaces as a single file.

* **Export app** lives in the editor's more menu (the ⋮ button in the editor bar)
  and downloads the app as a portable bundle: a `.json` file named after the app.
  It exports the app's published version, so publish before exporting. The bundle
  carries the structure of the app - its pipeline nodes, the Knowledge Base, and
  the Visualisation - but not the rows of data in it.
* The import button (**Import an app file**) sits at the top right of the **Apps** page, and
  each space's header carries its
  own import button wherever you may import into that space. Pick a bundle file and Ovidens
  creates a new app from it and opens it - in that space, from a space's header or when only
  one space is shown; otherwise, if you may import into more than one space, Ovidens first asks
  which space the app goes into, starting on **Workspace** where you may import there. In a
  workspace with no apps yet, the welcome screen offers **Import app** the same way. If the file is not a valid
  bundle you get "That file is not a valid app bundle." and nothing is created.

Exporting needs the **App builder** or **Admin** role on the app. Importing needs it on
the space the app goes into - and every member may import into **My space**.