Portals
A portal is a page of yours, hosted by the platform, with its own address and a button that runs the automations in your project. It is how you hand an automation to people who do not use the dashboard: sales, operations, the board.
The content is plain HTML — what you write is what shows up. The platform takes care of three things: hosting it, controlling who gets in, and giving the page a safe way to start automations.
Creating one
In the dashboard, under Portals, pick the project, give it a title and an address (lowercase letters, digits and hyphens) and click Create portal. You write the content right there — or let an automation publish it, which is the natural path when the page shows a report that changes on its own.
A portal lives inside a project, and the project is what decides which automations it can reach.
Opening, closing and replacing the link
Creating and releasing are separate decisions: a freshly created portal starts Closed.
| Action in the dashboard | What happens |
|---|---|
| Open by link | the portal gets its own address, outside the dashboard |
| Copy link | the address, always the same one, to send or bookmark |
| Replace the link | mints another address and immediately kills every link already out there |
| Close | anyone holding the link now sees "not available" |
Who can get in
The address alone does not open it. Whoever clicks must be signed in and belong to the account that owns the portal. The link is the address, not the credential — and it stays revocable at any moment through Replace the link.
For people who only need to see portals, the Team screen has the "portals only" role: they sign in, see the portals released to them, and no other screen of the platform.
Running an automation from the page
Inside the portal there is a datallog object, injected by the platform:
<button id="run">Refresh</button>
<pre id="out"></pre>
<script>
document.getElementById('run').addEventListener('click', async () => {
const r = await datallog.run('report', { month: '2026-10' });
const body = r && r.result !== undefined ? r.result : r;
document.getElementById('out').textContent = JSON.stringify(body, null, 2);
});
</script>datallog.run(automation, seed) starts an automation in the same project as the portal — the project is the boundary. The seed reaches your Python function exactly as it would through any other path.
What comes back depends on how the automation responds:
- on Wait for the result, the response already carries the result;
- on Run in the background — or when the run goes past the call budget — you get a body with an
exec_uuid, and the run stays alive: the result arrives through the webhook and the execution history.
Handle both cases, or the screen will sit waiting for a result that is coming down another road.
There is no run limit: the portal runs any automation in its project, and anyone with the link can trigger it. To cut access, close the portal or replace the link.
The page's isolation, and what it blocks
The HTML is yours, and it runs on the same domain as our API. So that a portal's code cannot reach the session of whoever opened it, the platform serves the content inside an <iframe sandbox> without allow-same-origin, and repeats the rule in a Content-Security-Policy header.
In practice the page is born in an opaque origin. That has consequences worth knowing before you write the screen:
| What does not work | What to do instead |
|---|---|
localStorage, sessionStorage, IndexedDB (they throw SecurityError) | keep state in the tab's memory, or have the automation store it |
document.cookie | the platform already identifies whoever opened it |
reading or writing the parent document (window.parent) | nothing to do: that is the isolation working |
| calling our API with the visitor's session | use datallog.run, which carries the right credential |
A preference that must survive a reload
With no local storage, a choice made on screen (a filter, a name, a tab) only lives while the tab is open. If it has to last, store it through the automation and read it back when the page opens.
The rest of the sandbox allows what a screen needs: scripts, forms, modals and opening links in a new tab.
Checklist for a new portal
- create the portal in the dashboard and write (or publish) the content;
- Open by link and copy the address;
- switch the automations the page calls to Wait for the result, so answers come back immediately;
- test it inside the portal, not by opening the HTML on your machine — the isolation only applies there;
- if the link gets out of your hands, Replace the link.