Skip to content

Apps (workflows, forms and dashboards together)

An app is a folder in your account that groups everything that makes up one solution: its workflows, forms, dashboards, document templates and DataStore groups. It keeps your account from turning into a flat list of resources and lets you see at a glance how everything fits together and where it starts.

Open it from the side menu, under Apps.


There is no new resource type: an app is a folder marked as an app. You get apps in two ways:

  • When you install a Library template. A folder is created with the name you choose, by default inside a container folder called “Apps”, so it stays apart from your own folders.
  • By converting a folder you already have. On the Apps screen, use Convert to app. Remove from apps turns it back into a normal folder; nothing is deleted.

When you install from the Library, the Create the app in your account dialog asks for:

  • App name. This is the folder name. If another one with the same name exists, (2) is added.
  • Where to create it. By default In the “Apps” folder (recommended). You can also pick another parent folder or No parent folder (root).
  • Publish on install (optional). By default everything is created unpublished. Forms or dashboards you tick get a public link: anyone with the link can open them.

Workflows are always created inactive until you activate them.

When it finishes, the setup guide has the main button Go to the app, which opens the installed app. Open the workflow is still available separately.


Opening an app shows four tabs:

  • Map: a read-only diagram with four columns: entries → workflows → data → outputs.
  • Entry points: the list of how the app is started (form, webhook, schedule, manual / API…).
  • Workflows, Forms and the other resource lists of the app.

At the top you have Back to Apps and the Refresh button.

Each card is a resource. Arrows show who uses whom (for example a form that triggers a workflow, or a workflow that saves to a data group). Each form or dashboard shows whether it is Published or Unpublished, and each workflow shows its last run or No runs yet.

Each row shows the type (Form, Webhook, Schedule, Manual / API, Data change, Error from another workflow, MQTT message, Redis message, Agent follow-up), its status and its link.

Forms and dashboards in an app have a menu with two options:

  • Test: opens the public link in a new tab.
  • Copy URL: copies the link and shows “URL copied”.

If the form or dashboard is not published yet, the menu is disabled and tells you why. Webhooks keep the copy-link icon.


The Connections tab, inside Apps, draws how apps link to each other. A link appears when a form, workflow or dashboard points to a resource in another folder. It also shows:

  • Data used by several apps.
  • Folders that look like a single app: folders with many links between them.
  • Broken links: they point to something that no longer exists, so whatever depends on them never fires.
  • Recent changes, with an Undo button.

Turn on Hide apps without connections to see only the ones that relate to others.

On an app’s map, the other apps it connects to are drawn as a single node per app, with its direction (incoming, outgoing or both ways). Back to “X” takes you back to the previous app.


Only an administrator can reorganize. Every action shows a preview (“See what will happen”) before it is applied and can be undone from Recent changes.

  • Group folders into an app: creates a new folder marked as an app and the chosen folders become its subfolders. You must choose at least two. Links that used to cross between them become internal.
  • Move to an app: moves forms, dashboards, document templates or DataStore groups to another app. If other items use them from other apps, they keep working.

The portal turns an app into a page with a menu: a single link that opens the app with a side or top menu and, in the body, the dashboard or form the visitor picks. It is what you show your team or your customers instead of passing one link per screen.

  1. Open the app (Apps → your app) and click Portal. Only administrators can change it; other users can view it.
  2. Set a name and choose the menu: Side (on the left, collapsible) or Top (tabs at the top).
  3. Choose the menu screens: the app’s dashboards and forms. You can rename each one, reorder them with the arrows and remove the ones you do not want; anything missing is added from “Add to menu”.
  4. Click Save (draft) and Publish. The portal link appears (https://your-domain/a/<token>), with buttons to copy and open it.

Until you publish, nobody sees the portal. If you change something later, users keep seeing the previous version until you click Publish changes. Unpublish makes the link stop working; when you publish again the same link is kept.

  • A menu with the app name and its screens, and the chosen screen’s content in the body. Every screen has its own address (…/a/<token>#d123), so the browser Back button and bookmarks work.
  • On the side menu, a button to collapse it to icons only and another to refresh the screen. On mobile the menu becomes a panel opened with the hamburger button.
  • Dashboards in the portal carry their filter bar (dates, selectors, search).
  • Forms in the portal do not end on a final page: on submit, the result (success, warning or error, with its links) shows in a notice above the form and, if it went well, the form returns to its initial state so the user can keep using the app. If it fails, what was typed is kept so it can be fixed.
  • A screen that is not published yet shows in the menu with a warning dot and, when opened, a “not published yet” message.

Security: what the portal does and does not do

Section titled “Security: what the portal does and does not do”

The portal only arranges and displays the screens. Every dashboard and form keeps its own public link and its own security. So:

  • If you want a username and password to be required, give the app’s folder a security group (dashboards and forms inherit it). Inside the portal each screen will ask to sign in and, without a session, does not show its content.
  • Anyone with the portal link can see the names of the menu screens, even if their content is protected.
  • The portal link is a random code; a code that does not exist, or an unpublished portal, return the same “not found”.

Library templates can bring their portal ready-made. On install it is created as a draft, with all its screens: just open the app, click Portal and Publish. When you undo the install, the portal is removed with it. An example is the Hub Fiscal sales and Sage panel.

Each app has one portal. Screens do not pass data to each other, and the portal has no roles or data editing of its own: those are planned capabilities, not available today.


  • When you pick a folder in the Workflows, Forms, Dashboards, Templates and DataStore lists, the Include subfolders switch decides whether resources in its subfolders are shown too. Tree counters add up subfolders.
  • DataStore groups also have a folder, and the ones a template creates are placed inside its app’s folder.
  • Deleting a folder does not remove it for good: it is archived, and it cannot be done if it has subfolders. When you try, you are told what it contains.

Is an app the same as an app published for end users? Not exactly. The app organizes and shows your resources; to show it to other people it can have a portal: a page with a menu that gathers its dashboards and forms. An end-user portal with roles, data editing and parameters passed between screens is a planned capability that does not exist yet.

Does “Remove from apps” delete anything? No. The folder and all its content stay as they are; it just stops appearing under Apps.

Can I undo a reorganization? Yes, from Recent changes in the Connections tab.

Why don’t I see data arrows on the map? They depend on your account’s reference index. If it has not been generated yet, the map shows the resources but not the data links.