Admin Guide

For the workspace administrator of a Netridium client account — IT and system admins, controllers and accountants, and the consultants who set the workspace up. It covers everything you need to configure the product and run it day to day: connecting your systems, building and governing Apps, controlling access and spend, and administering users, security, and billing.

The core idea: you build a capability once — your users run it with one click and get a finished report or action back. They never see the prompt or the code, only a button, a short form, and a result.

This is the complete reference: the App types, connector setup provider by provider, and the pre-run input form are all covered here rather than in separate documents.

One thing has its own guide, because it is a language reference rather than an administration topic:

LogicScript — the LogicScript guide (the language reference).

Related: the User Guide, which you can hand to the people who only run things.

1. Concepts and vocabulary

Term	What it means
Workspace	Your isolated environment (also called a tenant). Every connector, App, user, run, and result belongs to exactly one workspace and never crosses into another.
App	The unit you build and your users run. One App = one capability: a report, a reconciliation, an export, an update. Sometimes referred to as a LogicScript in older material.
Type	How an App is authored: Prompt or LogicScript. See §6.
Connector	A governed connection to one of your systems of record — NetSuite, Salesforce, Maxio, QuickBooks Online, Xero, HubSpot. Credentials are encrypted and never shared across workspaces.
Run / Report	One execution of an App and the result it produced. Every run is kept in History with its inputs, status, and cost.
Role	A named group of users. Each role is granted View and Run per App.
Cost center	An optional label on an App so its usage can be attributed (and budgeted) internally.
Plan (product)	What your workspace is entitled to. Several features below are sold per plan — each one is flagged. Your service provider or Netridium sets it.
Service provider	The firm that manages your workspace, if you have one. Shown read-only under Settings → General.
Admin	A member whose role is an admin role. Admins see every App and every admin page; everyone else is gated by their role.

2. Where things live

The left sidebar is the whole map. Pinned (your pinned Apps, grouped into their folders) and Recent (the last five Apps you opened or ran) sit at the top; the fixed links sit at the bottom.

Page	Who sees it	What it’s for
Inbox	Everyone	Runs that have paused and are waiting for you to answer a question, with a count.
Apps	Everyone	The catalog. Build, edit, run, and view results.
History	Everyone	Every run. Admins see the whole workspace; users see their own.
Usage	Admins	Token and cost usage, by day, app, cost center, and user.
Audit Log	Admins	Every meaningful action, with CSV export.
Users	Admins	Members, roles, invitations, approval, two-step status.
Roles	Admins	Define roles and grant View / Run per App.
Settings	Admins	Everything below.

Settings tabs: General · Account · Billing · Cost Centers* · Run limits · Budgets* · Connectors · Security · Single sign-on*.

* Shown only on plans that include the feature. Anything you already configured stays in force even if the tab later disappears — hiding the controls never lifts a limit.

Your profile (top-right menu → Profile) is separate from Settings and is available to everyone: your name, email address, password, and two-step verification.

3. First-time setup

Confirm your workspace details — Settings → General: workspace name, address, phone, primary contact, and currency.
Connect at least one system — Settings → Connectors (§4). An App cannot be saved without a connector.
Build your first App (§5–6) and run it to confirm data flows.
Set ceilings before you open it up — Settings → Run limits, and Settings → Budgets if your plan includes them (§10).
Create roles and invite your team (§12–13) so the right people can run it.
Decide your notification policy — Settings → General → Notifications (§11).
Tighten sign-in — admins already use two-step verification; Settings → Security requires it of everyone, or use Settings → Single sign-on if you have an identity provider (§14).
Add your own Anthropic key if your plan requires one (you’ll be asked for it before anything else), or optionally if it doesn’t — Settings → Billing (§10.6).

4. Connecting your systems

Settings → Connectors. Admin-only. Each workspace connects its own accounts; credentials are encrypted at rest and are never returned to the browser.

The page has two halves:

Connection cards at the top — one-click OAuth for Xero, QuickBooks Online, and Salesforce. Connect once and the org/company becomes a connector.
Add connector — for Maxio, NetSuite, and HubSpot, which you add as a row and then either connect (OAuth) or paste credentials into.

Which types you’re offered depends on your plan. Connectors you already have keep working even if the plan later narrows.

4.1 Xero

What you get: the organisation’s accounting data — invoices, contacts, accounts, payments, bank transactions, and the P&L, Balance Sheet and Trial Balance reports — plus creating and updating invoices, contacts and payments where the gates in §7 allow it.

Prerequisite: Netridium must have configured the platform Xero app. One Xero organisation per workspace.

Find the Xero card and click Connect Xero.
Authorize in Xero and pick the organisation.
The card shows Connected with the org name; the org is now a connector you can add to an App.

While connected, use Test connection to check the saved authorization still works. The organisation is fixed while connected: Reconnect returns to the same one, and to switch you Disconnect first. See §4.8.

4.2 QuickBooks Online

What you get: the company’s customers, invoices, apps, chart of accounts, vendors, bills and payments, plus a general query tool — and creating or updating customers, invoices and payments where the gates in §7 allow it.

Prerequisite: Netridium must have configured the platform Intuit app. One QuickBooks company per workspace.

Choose the Environment — Production or Sandbox. This is a required, explicit choice with no default; the Connect button stays disabled until you pick one. It must match the company you’re authorizing.
Click Connect QuickBooks → authorize in Intuit → choose the company.
The card shows Connected, the company name, and an environment badge.

While connected, use Test connection to check the saved authorization still works. The company and environment are fixed while connected: Reconnect returns to the same company in the same environment, and to switch either you Disconnect first. See §4.8.

Production needs Intuit approval. QuickBooks Production works only once Netridium’s Intuit app has passed Intuit’s production review. Until then use Sandbox with an Intuit sandbox company.

4.3 Salesforce

What you get: query the org with SOQL, list and describe objects, and read records — and create or update records where the gates in §7 allow it.

Prerequisite: Netridium must have configured the platform Salesforce Connected App. If Connect errors with “Salesforce OAuth isn’t configured”, that step is pending. One Salesforce org per workspace.

Choose the Environment — Production or Sandbox. Required, no default; Sandbox authorizes via Salesforce’s test.salesforce.com.
Click Connect Salesforce → log in → Allow. Salesforce always asks you to sign in, so use the credentials for the org you mean to connect.
The card shows Connected, the org name, Org ID, instance URL, the Salesforce user who authorized it, and an environment badge.

While connected, use Test connection to check the saved authorization still works. The org and environment are fixed while connected: Reconnect must sign in to the same org, and to switch either you Disconnect first. See §4.8.

4.4 Maxio

What you get: Maxio Advanced Billing and Core data — subscriptions, customers, invoices, products, and revenue data.

Maxio is OAuth-protected — you do not paste a token.

In Maxio, get your MCP server URL (looks like https://your-tenant.mcp.maxio.com/v2/mcp/…).
Add connector → Type: Maxio. Give it a display name, paste the URL, and leave API Token blank.
Save, then click Connect on the new row and authorize with Maxio. The row shows Connected.

A pasted token alone is rejected with a 401, even when the URL itself looks token-bearing. Always use Connect after saving.

4.5 NetSuite

What you get: Oracle NetSuite ERP through the NetSuite AI Connector Service — revenue, financial and operational data.

NetSuite uses a static bearer token — there is no Connect step.

In NetSuite’s AI Connector Service, get the MCP server URL, an Authorization Token, and your Account ID.
Add connector → Type: NetSuite. Fill in the display name, URL, token, and NetSuite Account ID (e.g. 1234567, or 1234567_SB1 for a sandbox).
Save. It is ready to use immediately.

When the token rotates, Edit the connector and paste the new one. Leaving the token field blank keeps the existing one.

4.6 HubSpot

What you get: HubSpot CRM — contacts, companies and deals — through HubSpot’s official MCP server.

Add connector → Type: HubSpot. Give it a display name. The MCP server URL is prefilled and is the same for every HubSpot account; leave API Token blank.
Save, then click Connect on the row and authorize with HubSpot.

4.7 Naming, notes, and status

Every connector has a display name and an optional note. The name is what authors pick from in the App editor, so name it for the account it points at — Xero — Holdings Ltd, not Xero. On the native cards the name and note are editable from the card itself.
Account ID. Each connector shows the ID of the account it points at, with a copy button. It appears in the connectors table, on the native cards, and in the edit dialog. The ID is filled in for you: Xero’s Organisation ID, QuickBooks’ Realm ID, Salesforce’s Org ID and HubSpot’s Portal ID are recorded when you connect. Maxio’s Site is read from the MCP server URL, and NetSuite’s is the Account ID you entered. Use it to confirm a connector points at the account you meant, for example production and not a sandbox.
Active / Inactive. Deactivating a connector takes it out of use without deleting it or its history. Deleting removes it entirely.
Allow Updates — the connector-level write gate. See §7.

4.8 Testing, reconnecting, and troubleshooting

Xero, QuickBooks and Salesforce follow one rule: a connection stays on the account you first connected it to. Only Disconnect, then Connect, can move it to a different organisation, company or environment.

Test connection — shown while a connection is working. It checks the saved authorization and reports back the account it reached, without a sign-in, so it can’t change anything. Use it before a big run, or to confirm a connection that has been idle.
Reconnect — shown only when a connection needs re-authorization, or hit an error. It signs you in again for the same account. Sign in to a different one and Netridium refuses it, leaving your connection exactly as it was: no App quietly starts reading another account’s data. QuickBooks also keeps its Sandbox/Production setting, so the environment picker is fixed.
Disconnect — the only way to change account or environment. Your Apps keep their connector, and start working again once you connect the new account.

Why the refusal matters: providers remember your last sign-in and may offer a different organisation or company. Before this rule, accepting that quietly re-pointed every App at the wrong books.

Symptom	Fix
Card shows Needs re-authorization	Click Reconnect — the stored token expired or was revoked. Sign in to the account already connected.
Reconnect says you signed in to a different org or company	Reconnect only restores the account already connected. Sign in to that one, or Disconnect first to switch.
Not sure a connection still works	Click Test connection. It names the account it reached, and changes nothing.
Card shows Error	A temporary failure. Test connection clears it if the connection is healthy again; if the test says re-authorize, use Reconnect.
“… OAuth isn’t configured” on Connect	Netridium hasn’t finished the platform OAuth app for that provider. Ask them.
A run fails with “rejected the credentials (401)”	Reconnect (OAuth connectors), or Edit and re-paste the token (NetSuite).
A Maxio run fails after pasting a token	Maxio needs OAuth. Clear the token and use Connect.
Connected, but results show test/sample data	The connection is on Sandbox. Reconnect keeps the environment, so Disconnect, then Connect and choose Production.
An app can’t write, and you expected it to	All three write gates must be on — see §7.
The connector type you want isn’t offered	Your plan doesn’t include it. Ask your provider.

After connecting, test it: open an App, add the connector, and run a simple read (“list 5 records”). If data comes back, you’re set.

5. The Apps page

Apps is both the catalog and the viewer.

Search filters by name, folder, and description. Apps are grouped into their folders.
Run launches an app (a form appears first if it takes inputs).
View opens the latest completed result — searchable tables, clickable record links, one-click Download.
Edit opens the editor (admins).
Pin puts an app in your own sidebar. Pins are per-user.
Select rows to Export them; Import brings a file of apps in. See §17.
New starts a new App.

6. Building an App

Apps → New, or Edit on an existing one. The editor is one page: a Details card, then what the app’s type is built from — the body for a Prompt or a LogicScript, or the cards for a Dashboard.

6.1 Details

Field	Notes
Title	What users see in the catalog. Required.
Folder	Free text; groups the app in lists and the sidebar. Existing folders autocomplete. Optional.
Cost center	(plan-gated) A managed list, not free text, so attribution can’t fork on a typo. Manage the list in Settings → Cost Centers.
Description	One line, shown under the title in the catalog.
Type	Prompt · LogicScript · Dashboard. See §6.2. Chosen when the app is created: after the first save it is shown but can’t be changed. To get the same app as another type, create a new one.
Model	Which model tier runs it (Prompt only).
Shape	How a Dashboard’s cards are laid out (Dashboard only).

The pin icon in the corner of the Details card shows the app under Pinned in your sidebar. Pins are per-user: it affects only your own sidebar, not anyone else’s.

Under those fields is a tab strip. Its first tab is named for the app’s type — Prompt, LogicScript, or Layout on a Dashboard — followed by Connectors, Inputs, Run limits, Options, Skills, and Documentation. One panel shows at a time. The first tab opens first and holds the app itself: the editor for its Prompt or LogicScript and, for a LogicScript, the Prompt box that Generate writes it from (§6.10). The others are covered in §6.4 to §6.8.

Documentation is a place for notes about the app — what it is for, who asked for it, what to check before changing it. Write them in Markdown and switch between Source and Preview, as for a Prompt’s body. The notes are saved with the app and travel with it when it is exported or published, but they are not part of what runs and are never sent to the AI. The tabs don’t carry counts; a badge appears only when a tab has something you’d otherwise have to open it to find out: None (no connector, so the app can’t save), Custom (this app overrides a run limit), Updates (this app may write back), or Unavailable (Skills aren’t usable on this workspace yet). Skills only appears on plans that include it. A Dashboard has no tab strip at all — none of those settings apply to it.

6.2 The types

An App you author is one of two types, and they differ by who owns the control flow — the plan for what happens in what order.

Type	Authoring	Who owns the plan
Prompt	Natural language	The model — you state a goal, it decides the steps, and answers in one pass.
LogicScript	A restricted Python dialect (logic plus marked AI steps)	You — Netridium runs your logic as code and calls the model only at the `ask` and `agent` steps you wrote.

They share the same plumbing: the same connectors, the same run queue and live status, the same pre-run inputs, the same run limits and write gates, and the same downloadable outputs. They differ only in how the work is expressed and executed.

One thing is LogicScript’s alone: a run can pause and ask a person — a yes/no, a pick-list, a short form, an approval — and continue when they answer. Those questions arrive in the Inbox.

There is also a third type, Dashboard, which runs nothing itself — it shows the latest results of other Apps side by side. See Dashboard below.

Availability is per plan. Prompt is everywhere; LogicScript is sold separately. The Type dropdown offers only what your plan permits (plus whatever the app is already set to, so an existing app never shows an invalid value).

At a glance

Dimension	Prompt	LogicScript
Authoring surface	Plain English	A restricted Python dialect
Control flow owned by	The model	You
Runtime	The model loops over your connectors’ tools, decides what to call, then answers	Netridium runs the script as code and calls the model only at `ask` / `agent` steps, each returning a typed, validated result
Stops when…	The model has answered	`run` returns
Repeatability	Low — the model picks the path each run	High for the logic and every number; an AI step returns the same shape each run, and its values may vary
Where the model reasons	Everywhere	Only at `ask` and `agent` steps
Pre-run inputs	Yes — fill `{{placeholders}}`, plus an appended block	Yes — bound to `def run(...)`’s parameters by name
Can change data	Yes, with all three gates (§7)	Yes, same gates — and AI output cannot reach a write until it is validated or approved
Model tier	Selectable	Per step: `model="fast"`, `"standard"` or `"deep"`
Batch processing	Yes	No
Agent Skills	Yes	No
Excel formatting	No	Yes — currency, dates, totals and highlights, on every plan (§6.12)
Typical cost	One pass	One small call per `ask`; nothing for the logic

Prompt (natural language)

You describe the outcome; the model orchestrates your connectors’ tools, analyses the data, and picks the output format. It owns the whole task and answers in one pass.

List all active subscriptions grouped by product, with MRR per group,
as an Excel sheet.

Strengths. Fastest to author. Ideal for ad-hoc and “fetch and present” reports, and it adapts when the data is messy.
Trade-offs. The less predictable of the two: two runs can take different paths or vary in shape. Pin it down with an explicit output instruction when consistency matters.
Only Prompt can use Batch processing and Agent Skills.

Agent (retired)

The goal-directed Agent type has been retired and can no longer be created or run. Two things replace it:

Generate (§6.10) — describe the goal in plain English and get a LogicScript that does it, written against your connectors’ real tools.
An agent step inside a LogicScript — for the part of a job whose path genuinely can’t be known in advance, with a typed result, a list of the tools it may read, and a step limit.

An app that still has the Agent type opens with it shown as Agent (retired): change its Type to Prompt or LogicScript and save. As a Prompt, its text works as written.

LogicScript (logic plus marked AI steps)

You write a script, and Netridium runs it — the logic, the arithmetic and every connector call execute as code, the same way every time. The script is written in a restricted dialect of Python: it reads as Python and your editor highlights it as Python, but only the parts that can be run safely and repeatably are allowed. The model is called only where the script says ask (one question, one typed answer) or agent (a bounded loop over read-only tools you list). What comes back is checked against a Shape you declared, and it is treated as untrusted: it cannot reach a connector write until the script has validated it or a person has approved it.

class Urgency(Shape):
    priority: Enum["low", "medium", "high"]
    reason: str = field(max_len=200, required=False)


def run(as_of: Date):
    invoices = query(
        QBO.Invoice,
        select=["Id", "DocNumber", "Balance", "DueDate"],
        where=[QBO.Invoice.Balance > 0],
    )
    overdue = [i for i in invoices if i.DueDate < as_of]

    u = ask(Urgency, "How urgent is this overdue balance?", data={"invoices": overdue}, model="fast")

    return {"priority": u.priority, "total": sum(i.Balance for i in overdue), "invoices": len(overdue)}

Strengths. Totals and writes are exact and repeatable. AI steps are small, typed and cheap. A run can pause for a person (request_…, approve) and resume where it stopped. A script with a mistake is refused when you save it, with the line number and what to write instead, rather than failing at run time.
Trade-offs. More to author than a Prompt, and you must declare the shape of every AI answer. It is a deliberately small language: no libraries, no while, and only the everyday methods on text, lists and dicts. It is also strict — adding text to a number is an error, not a guess — so an amount a connector sends as text is converted on purpose with float(…).
Dry run. Beside Run on the edit page (named Test draft on a plan with versions and approval). It runs the saved script read-only: where the script would change a record, it shows what it would have sent instead of sending it. Use it to try a script that writes.
Flow (where your plan includes it). The script’s card switches between Code, Flow and Split. Flow draws the script as steps — reads, AI decisions, questions to a person, changes — for anyone who would rather not read code, and can lay one of the app’s recent runs over it, step by step. It is a view: logic is still written in the code.
Versions and approval (where your plan includes it). The script you save is a draft; users and schedules run the latest version a workspace admin approved on the edit page. Turning on Allow updates needs a fresh approval.
Parameters (where your plan includes it). Values the script declares as Parameters — a threshold, an approver — can be changed on the edit page without editing the script.
Scheduling. A scheduled LogicScript that asks a question waits for the schedule’s owner (or the role you named) to answer in their Inbox.
Full reference: the LogicScript guide.

Script (retired)

The Script (Python) type has been retired and can no longer be created or run. LogicScript is the one way to write an app as code. It is a restricted Python, so a script reads the same — and unlike a Python script, Netridium can see what it will do: every connector call is a visible step, AI output cannot reach an update unchecked, a Dry run shows the changes without making them, and a run can pause for a person.

An app that still has the Script type opens with it shown as Script (retired): change its Type to LogicScript, rewrite the script (the Generate LogicScript helper in §6.10 will draft it from a description of what the old one did), and save. What differs from Python is listed in the LogicScript guide, under What is not Python here.

Which should I use?

Prompt when the request is essentially “get this data and show it” and you’re happy for the model to work out the how.
LogicScript when the process and the numbers must be exact — defined steps, real arithmetic, controlled writes, a person’s approval — and the model is needed only for judgement at marked steps.
Dashboard when you already have the apps and want their results on one page.

A rough rule: Prompt = “what I want.” LogicScript = “these exact steps, with AI where I say.”

Dashboard (other apps’ results, side by side)

A Dashboard runs nothing itself. It lays out cards, and each card shows the latest result of another App — an Excel table, a chart image, HTML, a PDF — so related results sit on one page.

Setup. Choose Dashboard as the Type, then a Shape. Shapes read as cards per row: 2 is two side by side; 1x2 is one wide card above two; 1x3, 2x2, 2x3 and 3x3 follow the same rule. The Dashboard panel below Details shows the cards in that shape; pick an App for each. Every card needs one. Each card also has an optional Rows — its height in grid rows (blank is 2, up to 6). Cards side by side share a height, so a row is as tall as its tallest card.
What it doesn’t have. No body, connectors, inputs, run limits, options, schedule or Allow updates — those belong to the apps on its cards.
Running. Each card has its own Run, and Run all runs every card at once. A card runs as its own app, so that app’s inputs, run limits, budget, role permissions and write gates all apply. Run all skips cards that ask for inputs or can change data; use their own Run, which shows the usual form or confirmation.
Who sees what. A card whose app was removed, deactivated, or isn’t shared with a user’s role shows as unavailable, without its title.
Limits. A dashboard can’t contain another dashboard or itself. Dashboards aren’t included in exports, imports, templates or catalog publishing, because their cards point at this workspace’s apps.
Availability. Sold per plan.

6.3 Model tiers

Offered on Prompt. Deeper tiers reason harder and cost more per run.

Tier	For
Claude Fable — Deep Analysis	The hardest analytical work.
Claude Opus — Complex Work	Complex, multi-step reasoning.
Claude Sonnet — Everyday Tasks	The default; the right answer most of the time.
Claude Haiku — Quick Answers	Simple, high-volume extraction and formatting.

These are tiers, not fixed model versions — Netridium moves a tier onto a newer model without you having to touch your apps. A LogicScript picks a tier per AI step (model="fast", "standard" or "deep"), so the field is hidden for it.

6.4 Connectors (required)

Tick the connector(s) this app may reach; each is listed with its account ID. An app with no connector cannot be saved — the badge reads None in red until you pick one. An app can only ever touch the connectors selected here, whatever its text says.

6.5 Inputs

See §8 — the pre-run form is worth its own section.

6.6 Run limits (per app)

The ceilings on a single run of this app: Max cost, Max duration (min), and — once Allow updates is on — Max updates. Leave a field blank to use the workspace default from Settings → Run limits; there is always a limit. The panel opens with the effective numbers — what will actually apply to a run — and the tab badge reads Custom as soon as you override one. Ticking Allow updates switches the app to the workspace’s limits for update runs. Full behaviour in §10.2.

6.7 Options

Active and Show links default on; the other three default off. The tab shows an Updates badge whenever Allow updates is on, so a write-enabled app never looks read-only from the strip, and an Inactive badge when Active is unticked.

Active — untick to take the app out of use without deleting it. An inactive app is kept, with its results, but can’t be run — by anyone, or by a schedule — and only admins still see it in the Apps list, marked Inactive. Tick it again to bring the app back. An app managed by your service provider can’t be changed here.
Show links — turns any full URL the app returns into a clickable link, so records link back to their source system.
View feedback — while the app runs, admins see a live log of each step in the results pane: every connector call and what the AI says it’s doing between them. The log is kept with the run, so a failed run shows how far it got. It only records; it never changes how the app runs. Only admins see it. Batch runs don’t stream steps. The setting stays with this workspace and isn’t included when the app is exported or published.
Batch processing — submits a Prompt through the batch API: roughly half the cost, but results take longer. Prompt only, and not with a Skill.
Allow updates — Gate A of the write policy. See §7.

6.8 Skills (plan-gated, Prompt only)

Normally the app returns data and the portal builds the file. A Skill instead has the model write the file itself, so it can produce things the built-in outputs can’t.

Skill	What it produces
Excel workbook	Live formulas, multiple linked sheets, charts.
Word document	Formatted reports; can fill an existing template.
PowerPoint deck	Slides with layout, tables, and charts.
PDF document	Rich layout and tables the built-in PDF can’t produce.

Three things to know:

The layout is decided per run, so it can vary between runs of the same app. If you need an identical layout every time, don’t use a Skill.
Skills require your workspace to run on its own Anthropic API key, on a plan that requires it — the file is created in your Anthropic account, not Netridium’s. If that isn’t the case the tab reads Unavailable and the panel says why.
Batch processing is unavailable while a Skill is selected.

If what you need is a well-presented spreadsheet — amounts as currency, dates, a totals row, cells coloured by a rule — a LogicScript can do that on any plan and either key, with no Skill: see Excel formatting (§6.12).

6.9 The body

The first tab — Prompt or LogicScript — holds what you actually write.

Templates. Where templates exist for the type, a Template… picker appears above the editor. It copies the text in; the app is not linked to the template afterwards, so later template changes don’t reach it.

6.10 Generate (LogicScript)

Describe the process in the Prompt box on the LogicScript tab and click Generate LogicScript. When the app already has a script, choose Update or Overwrite beside the button. With Update the button reads Generate changes and the script is edited rather than rewritten; with Overwrite a new script replaces it. Either way, Undo in the editor restores the previous one. Netridium writes it against your selected connectors’ real tools, compiles it and checks every connector call, and fixes what the check finds. Under the box you see what the script does in plain English, and any inputs it added to the Inputs tab. Review it, save it, and try it with Dry run. You must select at least one connector first; the button is disabled without one.

By default Generate does not run the script. Tick Use live read-only data and it runs it once against your connected systems — reading for real, changing nothing, leaving no run in History, asking nobody — and fixes what that run finds, usually a wrong guess about what a connector returns. It asks for input values first when the script takes any, and it takes longer and costs more. When the try ran to the end, See what it produced shows the actual result under the box: read it before saving, because a script can run cleanly and still say the wrong thing. Cancel stops a Generate in progress within seconds, including what it would have spent.

Generate uses a more capable model and may take several attempts, so it costs several times a normal run. It is capped separately by Max cost per Generate (§10.4) and is not covered by run limits or budgets.

New · Duplicate · Add to catalog · Schedule · Delete, then Cancel · Save · Run. Live run status and an Unsaved / Saved marker sit to their left.

A new app shows only Cancel and the create button until its first save.
A LogicScript has Dry run between Save and Run. On a plan with versions and approval, Run reads Test draft while the saved draft is not the approved version (§6.2).
Schedule appears where your plan includes scheduling, and never on a Dashboard.
Delete asks you to confirm before anything is removed.
Add to catalog appears only for service-provider staff working inside your workspace (§18).

Save before you run. Run acts on the saved version, so what executes is always what is stored. The button says so if you have pending edits.

6.12 Excel formatting (LogicScript)

By default a LogicScript’s table comes back as a plain spreadsheet: a header row, columns sized to fit, each value as it is. Excel formatting lets the script say how the workbook should look:

Number formats — currency (in any currency), whole numbers, decimals, percentages, dates and date-times.
Totals — a totals row under the data: sum, average, count, minimum or maximum, per column. Each total is a live Excel formula, so it recalculates if someone edits the file.
Highlights — colour the cells that meet a test (red, amber, green or bold): a balance over 10,000, a due date before today, a status equal to “Overdue”.
Column order and widths, and several sheets in one workbook — a summary and the detail behind it.

You don’t need to write it yourself. Ask for it when you Generate (§6.10) — “show balances as currency, add a total at the bottom, and highlight anything over $10,000 in red” — and Generate writes it. Authors writing by hand will find every setting under Formatting a workbook in the LogicScript Guide.

What to know:

It works on every plan and with either AI key. The file is built inside Netridium; nothing is sent to an outside service to make it. Unlike a Skill (§6.8), the layout is the same on every run.
The result looks the same in the browser as in the downloaded file: amounts, dates and highlights are shown as formatted.
The totals row is not data. It stays at the bottom when the result is sorted or filtered, isn’t counted in the row count, and covers every row even while a filter hides some. In Excel, sorting with the filter buttons doesn’t move it.
Number and date highlights stay live in Excel — change a value and its colour follows. A text match is coloured when the file is made, and doesn’t change if someone edits the cell.
Formulas are written by Netridium, never by the script. The totals are the only formulas in the file, and text from your systems that begins with = is always shown as text. A workbook can’t carry a formula that sends its contents anywhere when it’s opened.
Every Excel result has a size limit — 100,000 cells (rows × columns, all sheets) unless Netridium has set another. A larger result fails the run and says so; return fewer rows or columns.
A Prompt app can’t use it yet. It’s for LogicScript apps.

7. Read-only by default: how writes are governed

Netridium is read-only by default, whatever the type. A Prompt or a LogicScript can only list and read until you deliberately open a path for it. Enabling writes takes three explicit gates, each of which defaults off:

Gate	Where	What it says
A	App → Options → Allow updates	This app may create, update, or delete data.
B	Settings → Connectors → Allow Updates on the connector	This system may be written to.
C	The native connection (Xero / QBO / Salesforce)	The OAuth grant is read-write. Requested automatically when you connect; Gate B is the control you actually operate.

A write happens only where all of them line up. Any tool that isn’t clearly a read is hidden from an app that isn’t write-enabled, and rejected if it is somehow called — an unknown tool is treated as a write.

7.1 Allow updates: what it needs, and when it is required

Allow updates is available on every plan. It can be switched on when a max cost and a max duration resolve for the app — its own value, or the workspace default for update runs. Those defaults are always set, so in practice you tick the box. An update can’t be undone from here, so an updating run is never unbounded in money or time, and it is also held to Max updates (§10.2).

Your workspace does not need its own Anthropic key to update another system. On a plan without one, updating apps run like any other and draw on your usage credits.

An app that updates must have it on. If a LogicScript calls a tool that the connected system itself describes as changing data, saving it with Allow updates off is refused, and the message names the line. Tick Allow updates, or remove the call. This is checked against the connector’s real list of tools, so a tool that only sounds like an update never blocks a save.

A Prompt app is plain language, so it can’t be checked when you save it. If one tries to update something while Allow updates is off, the update is refused and the result says so: This run tried to update a connected system and was stopped: Allow updates is off, on this App or on the connector. Nothing was changed.

If a scheduled run later fails the ceiling condition, it is refused, not quietly downgraded to read-only. An integration that silently stops writing gets debugged as a broken connector.

7.2 Every write-enabled run confirms

When an app has Allow updates on, the runner sees a confirmation before it starts — with or without inputs. Where there are inputs, their values are read back for checking, because values you got wrong will be written as given. Where there are none, the warning stands alone: there is no preview and no undo.

7.3 Everything is audited

Every connector write is recorded in the Audit Log as connector.write, alongside the run and the user.

8. Inputs (the pre-run form)

An App can declare a small set of inputs collected from the user before a run starts. They fill a short form, click Run, and the values are woven into the app as it executes. The run itself is unchanged — still queue, run, result; the form is the only point of human interaction, and it happens up front.

Both types support it: Prompt fills {{placeholders}}, and LogicScript receives the values as its def run(...) parameters.

Use it for genuinely reusable tools — “email this template to a chosen recipient”, “reconcile these accounts for this period” — where the app is fixed but a few values change per run. One parameterised app beats twelve near-identical ones.

Inputs aren’t sold separately: every plan that can author an app can parameterise it.

8.1 Defining a field

Open the app in Edit and choose the Inputs tab. Click Add input for each value.

Property	What it is
Key	The identifier used in the body as `{{key}}`. Letters, digits, and `_`; must start with a letter or `_` (e.g. `account_id`). Unique within the app.
Label	The human-friendly prompt shown in the run form (e.g. “Account”).
Type	How the field renders and is validated — see below.
Options	Dropdown only: a comma-separated list of choices.
Required	The form won’t submit until the field has a value.
Max length	Text only. Caps the value’s length.
Minimum / Maximum	Number only. Inclusive bounds.
Earliest / Latest	Date only. Inclusive bounds.
Help text	Shown under the field in the run form. The cheapest way to prevent a wrong value: it stops one being typed at all.

Incomplete rows (no key or label) are dropped on save, so a half-filled row never breaks anything. Save validates the keys, their uniqueness, that a Dropdown has options, and that no constraint contradicts itself.

8.2 Field types

Type	Run-form control	Arrives as
Text	Single-line text box	string
Number	Numeric input	number (a real number — `25`, not `"25"`)
Yes / No	Checkbox	boolean
Date	Date picker	string, `YYYY-MM-DD`
Dropdown	Select menu, from Options	string, one of the options

8.3 Constraints

Every constraint is optional and each applies to exactly one type. They exist to catch a mistake — a typo’d year, an extra zero, a paste of the wrong thing — not to express a format. Runners are trusted people in your workspace; what you’re guarding against is a slip, and a slip on an app that can write is expensive.

Constraint	Applies to	Effect
Required	All	No value, no run.
Options	Dropdown	The value must be on the list, exactly (case-sensitive).
Max length	Text	Rejects a longer value.
Minimum / Maximum	Number	Inclusive bounds.
Earliest / Latest	Date	Inclusive bounds.

Help text is worth more than any of them. “Use the period END date”, “Comma-separated account codes, e.g. 4000,4100”, “Sandbox account numbers won’t resolve here” — each stops the wrong value being typed at all, which no validation rule can do. Write it for every field whose right answer isn’t obvious from the label.

Ceilings you can’t raise

Two limits apply whatever you configure: 4,000 characters for a single value and 20,000 for all of a run’s values together. A Max length above the first is clamped to it. An uncapped text box is an uncapped prompt and an uncapped bill — someone pasting a document into a “customer name” field is the case these exist for.

When a setting is unusable

A configuration that can’t be enforced stops the run rather than being quietly skipped: a Dropdown with no options accepts nothing, and a reversed range (a minimum above its maximum, an earliest after its latest) stops the run and names the field, so you hear about it.

The one exception: a constraint left behind on the wrong type — say a minimum on a field you switched from Number to Text — is ignored rather than treated as an error, so changing a type can never strand an app nobody can run.

There are no format or regex rules

Deliberately. A pattern written by one workspace would be compiled and run on the shared server on every submit, so one pathological pattern becomes everyone’s outage. Where a field needs a shape the constraints above can’t express, say so in Help text and check it inside the app.

8.4 Using the values

Prompt. Reference any input by its key in double braces:

Draft a friendly reminder email to {{recipient}} about invoice {{invoice_no}}.
Keep the tone {{tone}}.

Two things happen at run time:

Placeholder substitution — every {{key}} is replaced with the value (whitespace inside the braces is tolerated, so {{ key }} works too).
An appended block — the values are also added at the end as a delimited list, so the model sees them even where you didn’t write a placeholder:
```
<run_inputs>
- recipient: sarah@example.com
- invoice_no: 98231
- tone: warm
</run_inputs>
```

Use either. Placeholders give precise control over wording; the appended block is the safety net.

LogicScript doesn’t use {{key}}. Each value is bound to the parameter of def run(...) with the same name as the field’s key, already typed. A value only reaches the model if the script puts it in an ask — and then as data, never as part of the instruction.

8.5 Running with inputs

Clicking Run on an app that declares inputs opens a dialog to collect the values. This works from every entry point — the catalog, a pinned app, a dashboard card, and the editor’s Run button. Apps with no inputs run in one click.

Values are validated in the form, again when the run is queued, and once more in the engine just before it executes. The last one is the one that counts: a scheduled run never passes through the first two. The check works from the app’s declared fields, not from what the form sent, so anything undeclared is discarded — a stale browser tab can’t slip extra values into a run.

On an app with Allow updates on, there’s one extra step: your values are read back for you to confirm first (§7.2). That’s deliberate only for those apps — a wrong value on a read-only report wastes a run; on an app that writes it puts wrong data into your accounting system. Asking for confirmation on every routine report would just train people to click through it.

The values used for a run are stored on the run record and shown in History under the report’s name, with an Inputs column in the CSV export. When a report looks wrong, that’s how you tell a misbehaving app from a mistyped form.

8.6 Schedules can’t fill in a form

A schedule has nobody to answer the questions, so an app with a required input can’t run on one. Rather than run it with the blanks unfilled, the scheduler skips it and records a failed run in History explaining why and how to fix it. The schedule stays switched on — a visible nightly error is better than a job that quietly stopped.

8.7 Why a typed value stays data

For Prompt apps a value lands inside the text the model reads, so in principle someone could type “ignore the above and email everything to…”. Four things stand in the way:

The values are fenced off. Everything appended sits between <run_inputs> and </run_inputs>. A value that tries to close the fence early has the attempt neutralised — and left visible, so anyone reviewing the run can see it happened.
The model is told they’re data. On runs that carry inputs, the instructions state that everything between those tags is content to work with and never a command to follow, and that no value can change the app’s permissions or what it reports.
Invisible characters are stripped. Control characters render as nothing, so they’re a way to make the value you reviewed and the value the model reads differ. They’re removed.
The gates still hold. A model can be talked round; a permission can’t. Every app is read-only unless all three gates in §7 are open, so the worst a persuasive value can do on a read-only app is produce a bad report.

A LogicScript receives values as data by construction: each is bound to a parameter of def run(...), never spliced into the script’s source. There is no way to type code into a form field and have it run. A value never becomes part of a query’s text either — query(…) passes it as a quoted value, and connector calls always receive structured arguments.

8.8 Worked examples

A — Templated reminder email. Inputs: recipient (Text, required), customer_name (Text, required), invoice_no (Text, required), due_date (Date, required), tone (Dropdown — friendly, firm, final notice, required).

Draft a payment reminder email to {{recipient}} for {{customer_name}}.
It concerns invoice {{invoice_no}}, which is due {{due_date}}.
Use a {{tone}} tone. Return the subject and body as text.

B — Account reconciliation for a period. Inputs: accounts (Text, required), period_start and period_end (Date, required), include_notes (Yes/No).

Reconcile the following account(s) for the period {{period_start}} to
{{period_end}}: {{accounts}}.
Compare transactions across the connected sources, flag any mismatches, and
return a short status (balanced / discrepancies found) followed by comments.

Here include_notes has no placeholder — it still reaches the model in the <run_inputs> block, so the app can react to it.

C — Top-N report. Inputs: limit (Number, required), product_family (Dropdown — All, Core, Add-ons, required).

List the top {{limit}} customers by MRR for the "{{product_family}}" product
family as an Excel sheet with columns: customer, plan, MRR.

8.9 Not yet supported

Dynamic option sources. Dropdown options are a static list. Pulling choices from a connector query (“pick from your Xero accounts”), or a workspace user picker, is a planned follow-up.
Values stored on a schedule. See §8.6.
Default values. The form opens empty; use Help text to state the expected shape.
Format / regex rules. Deliberately not offered — see §8.3.

Inputs travel with an app through export / import and catalog publishing, so a parameterised app moves between workspaces intact.

9. Running, History, and results

9.1 Running

Start a run from the catalog, from a pinned app in the sidebar, or from the editor. If the app takes inputs the form appears first; if it is write-enabled, the confirmation appears too (§7.2).

Runs are processed in the background — the status updates live and you can move around the portal. Statuses are Queued, Running, Needs input, Ready, Failed, and Canceled. Needs input is a LogicScript that has paused to ask a person a question; it carries an Answer button, and the question also appears in that person’s Inbox. You can Cancel a run in progress; a canceled run never sends a notification email.

9.2 Results

Results render in the browser. Depending on what the app returns you’ll see a spreadsheet with tabs, a formatted HTML document, a PDF, an image or chart, plain text, or structured data. Word and PowerPoint files (written by a Skill) are offered as a download rather than a preview. Download saves the result; for an HTML document the button is Save as PDF.

An HTML document is shown exactly as the App wrote it, and nothing in it is loaded from another site — no linked image, stylesheet or font. That keeps a report from sending its contents anywhere when someone opens it. A report that links a remote logo shows no logo; one that names a web font uses a system font.

A spreadsheet can be searched, sorted by any column, and filtered one column at a time — a filter understands comparisons such as > 1200 and 2026-01-01..2026-03-31. Where the app uses Excel formatting (§6.12), amounts, dates and highlights show as they do in the file, and a totals row stays pinned below the data, out of sorting, filtering and the row count. Sorting and filters always use the value, not how it’s shown: > 12000 finds $12,500.00. Each person can save a filtered, sorted arrangement as a named View and return to it after the app is re-run. Views are per-person. The User Guide has the filter syntax.

Where Show links is on, IDs and URLs in tables are clickable through to the record in the source system.

Where View feedback is on (§6.7), admins also see a Live run log above the result while the app runs. Once the run ends, it becomes a collapsed Run log you can reopen. It opens automatically when the run failed, because that’s where it tells you what the run was doing when it stopped.

9.3 History

History lists the most recent 100 runs: report, type, who ran it, when, and status, with the inputs each one carried under its name. Badges mark a Scheduled, Batch or Dry run run. Admins see the whole workspace; other users see their own. Any completed report can be re-opened or downloaded, and the list exports to CSV. To run an app again, use Run on the Apps page.

10. Cost, limits, and budgets

Four distinct controls, each answering a different question.

Control	Scope	Where
Usage	What has been spent	Usage page
Run limits	One run	Settings → Run limits, and per app
Budgets	One calendar month	Settings → Budgets
Cost centers	Who it gets attributed to	Settings → Cost Centers

10.1 Usage

The Usage page shows metered usage for a date range you pick. A Summary gives your allotment for the period, what is used and what remains; under it is a daily breakdown by Folder, App, Cost Center, and User, with runs, tokens, usage, and billed amount. Download CSV saves the breakdown. The amounts are what appear on your invoice — use them to reconcile the bill. On a plan that requires your own Anthropic key, the money columns drop out and it becomes a run and token volume report.

10.2 Run limits

Guardrails for a single run, so one App can’t run away with your usage or with your records. Every run has them. Set the workspace’s limits in Settings → Run limits; override them on any app under Edit → Run limits.

The settings page has three groups:

Group	Limit	What it caps
All runs	Max duration	How long one run may be working, in minutes. Time spent waiting for a person to answer a question doesn’t count.
	Max cost per Generate	One use of the Generate button (§10.4).
Read-only runs	Max cost	How much AI usage one run may spend.
Update runs	Max cost	The same, for apps with Allow updates on.
	Max updates	The most changes one run may make to your connected systems.

A new workspace starts with 30 minutes, $10 a run for each kind, 500 updates, and $5 a Generate. Change them to suit.

Every field is required. There is no “no limit”. Blank on an app means “use the workspace’s limit”.
Read-only and update runs have separate cost limits so you can hold apps that change your records to a tighter number. A Dry run counts as read-only.
Max cost counts AI usage only. Reading from a connected system costs nothing and isn’t counted — a LogicScript can page through as much as it needs.
Max updates is the limit that matters for an app with no AI steps. Such an app spends nothing, so a cost limit would never stop it. Reads are never counted as updates.
An app’s own value wins, and the editor shows the workspace’s limit behind each blank field.
They are enforced while the run is happening, not checked at the end. A run that reaches any limit stops immediately and is marked failed, naming the limit it hit. Changes the run had already made stay made — stopping does not undo them.
Usage already incurred is still recorded and still billed — otherwise a tiny limit would be a way to consume AI spend for free. Partial results are normally discarded; the one exception is a run whose finishing turn is the one that crossed the ceiling, where the deliverable is kept (the spend already happened) and the overage is recorded against the run.

A good starting point: workspace limits comfortably above a normal run, then a tighter Max updates on any app that should only ever touch a handful of records.

One documented gap, on apps that use a Skill. Max cost still caps token spend on a Skills run, but it cannot include the time the model spends writing the file in Anthropic’s sandbox — that isn’t reported back in a form we can measure. Max duration is the ceiling that bounds it, and it does reach the in-flight call. Skills run on your own Anthropic key, so that time is billed to your Anthropic account.

10.3 Budgets (plan-gated)

Run limits cap a single run; budgets cap a calendar month (UTC). Both are optional and they work together — the run limit stops one runaway report, the budget stops a month of ordinary ones adding up past what you planned.

Field	What it caps
Workspace budget / month	Everything this workspace runs.
Budget / month, per cost center	Only apps tagged with that cost center.

Amounts are the same figures shown on the Usage page. Blank = no budget.
When a budget is reached, new runs are refused with a message naming it. A run admitted with less than its usual ceiling left is capped at whatever remains, so it stops rather than overshooting — and usage already incurred is still recorded and billed.
Where both apply, the stricter wins. A cost center with room still can’t run once the workspace total is spent. An app with no cost center still counts toward the workspace budget; the Budgets page shows a No cost center row so the per-cost-center figures visibly add up.
Budgets reset on the 1st. Nothing carries over.
Reassigning an app’s cost center does not move its past spend. History stays attributed to whichever cost center was set when each run happened — which is what stops a budget changing retroactively.
A workspace on a plan that requires its own Anthropic key is exempt, because Anthropic bills you directly and nothing is metered here. Use Run limits instead; the Budgets page says so.

10.4 The Generate limit

Max cost per Generate (on the Run limits page) covers the Generate button in the editor, and nothing else. It is deliberately separate from the three limits above and the two never affect each other — and budgets don’t cover it either, because Generate is an authoring action, not a run.

Generate uses a more capable model and retries against your real data, so it costs several times a normal run. Give it a noticeably higher ceiling. Set it too low and Generate stops partway and tells you so. It is always set; a new workspace starts at $5.

10.5 Cost centers (plan-gated)

Define the cost centers this workspace attributes usage to in Settings → Cost Centers, then assign one to each App in the editor. They appear on the Usage page, so you can charge usage back internally, and they can each carry their own monthly budget. A cost center can be made inactive rather than deleted, so historical attribution survives.

10.6 Your own Anthropic key (BYOK)

Settings → Billing → Anthropic API key. A workspace can run all of its AI on its own Anthropic account, keeping spend and data flow under its own control. The key is checked with Anthropic when you save it, stored encrypted, and never shown again.

Whether a key is required is set by your plan:

Required. Nobody in the workspace can use it until an admin saves a key. Everyone is held on an Add your Anthropic API key page; an admin enters the key there, and the workspace opens. The key can be replaced later but not removed. The workspace pays Anthropic directly, so usage credits and monthly budgets don’t apply.
Not required. Runs use Netridium’s key and draw on your usage credits, including apps that update other systems. You may still add your own key if you prefer; Remove takes it away again.

Agent Skills need a plan that requires the key rather than merely permits it. Allow updates does not depend on the key (§7.1).

Whether your plan requires a key is set by your provider — if you need it changed, ask them to move the workspace to a different plan.

10.7 Usage credits

Settings → Billing → Usage credits. Where your plan offers them, buy usage in blocks: pick the credit, a quantity, and whether this billing period is charged in full or prorated. It renews every billing period and is charged to your card at purchase. The card states exactly what lands now, what is charged now, and what recurs. Spend against it shows on the Usage page.

11. Notifications

Settings → General → Notifications.

Email when a run completes — Never, Scheduled & batch runs only, or Every run. The middle option is the useful default: it covers runs nobody is watching and stays quiet for one you launched and are watching on screen.
Email when a run fails — independent of the setting above, so a failure notifies even when success emails are off. On by default. A run someone cancels never emails; they already know.

Recipients are the person who ran the report plus this workspace’s admins. Links in the email point at the in-app viewer, so viewing still requires signing in.

12. Roles and permissions

Roles. Create a role per group of users — Finance, Ops, Read-only — then grant it, per App:

View — the role can see the app exists.
Run — the role can execute it. Run requires View.

Admins have access to everything; there is nothing to configure on an admin role. Everyone else sees exactly what their role permits — and never the prompt or the code behind it.

Roles can be made inactive. Publishing an app to exactly the right people, or revoking it from all of them at once, is a single change here.

Test before you publish. Run an app yourself, confirm the result, then grant Run.

13. Users and invitations

Users. One row per member, showing:

Column	Notes
Name	With the email underneath.
Role	Change it inline. You can’t change your own.
Sign-in	SSO or Password — how this person signs in. Shown only if your workspace uses single sign-on.
Email	Confirmed, or a Verify action if they never confirmed.
Two-step	Whether they’ve set up an authenticator — a tick or a cross.
Active	Approve a pending member. For an existing one, untick Active to block their access to this workspace without removing them; tick it to let them back in.

Invitations. Invite teammates by email and pick the role they’ll land in. Pending invitations are listed and can be resent or revoked. Where membership requires approval, a new member appears in the list and stays inert until an admin approves them.

Disabling a member keeps their history intact but ends their access.

14. Security

14.1 Passwords

Enforced server-side: at least 12 characters, not the account’s own name or email, and screened against a public corpus of passwords found in past breaches. There is no requirement to mix capitals, digits, and symbols — a memorable phrase of a few words is both easier to remember and harder to guess. The form shows what’s still missing as you type.

14.2 Two-step verification

Admins always use it. Every admin of a workspace must sign in with a code from an authenticator as well as their password. It isn’t a setting and it isn’t tied to your plan: an admin connects your systems, turns on updates and grants roles, so an admin’s password is never the only thing protecting them. A new admin is asked to set up an authenticator the first time they sign in. If you are the only admin and lose your authenticator, contact Netridium support to have it reset; with more than one admin, another admin can reset it from the Members table below.

Extending it to everyone — Settings → Security. Available on every plan. Tick Require two-step verification and everyone who reaches this workspace must sign in with a code from an authenticator as well as their password — your own members, your service provider, and Netridium support alike. Any authenticator app works.

Check the Members table on the same page before you turn it on. It lists who has an authenticator set up. Anyone without one is locked out of the workspace the moment you save, until they set one up — which they can do themselves from their Profile. The form warns you with a count before saving. The same table lets you reset a member’s authenticator when they have lost it, so they can enrol again.

Netridium support can grant themselves a short, recorded exception if they ever need to reach the workspace to fix something. It applies only to that person, only to this workspace, is time-boxed, and is written to your audit log.

14.3 Single sign-on (SAML) (plan-gated)

Your team can sign in with your own identity provider — Okta, Microsoft Entra ID, Ping, or any SAML 2.0 provider. Contact Netridium to set it up: they’ll ask for your provider’s metadata URL and the email domains you own, and give you the two values (EntityID and ACS URL) your identity administrator needs. Your current settings are visible under Settings → Single sign-on.

Once connected, people choose Sign in with SSO on the login page and enter their work email. You can have new users created automatically on first sign-in, and you can require SSO so passwords stop working for your workspace.

Admins always sign in with a password. Single sign-on never gives anyone the Admin role, and an account that signs in through your identity provider can’t be promoted to it. Your admins keep their password sign-in even when SSO is required, with two-step verification as every admin has. This means an outage or a mistake at your identity provider can’t lock your admins out, and can’t create one. It also means removing an admin from your identity provider does not remove their access here: deactivate them under Users.

The Sign-in column on the Users page shows which is which. Everyone marked Password is outside your identity provider, so that is the list to check when someone leaves; anyone marked SSO can’t be made an Admin.

Three things worth knowing:

Signing out of your identity provider doesn’t end an active session here. Sessions expire on their own schedule.
If someone already had a password account, their first SSO sign-in creates a new one. The old account is retired so it doesn’t take up a seat, but reports they ran before the switch stay listed under it.
An admin who uses Sign in with SSO is not moved. Their admin account is left exactly as it is and no second account is made; they sign in with their password as usual.

14.4 Service provider access

Settings → Security → Service Provider Access. Control whether your service provider (through their Company Manager) and Netridium’s System Manager may open this workspace. Access can be granted for a set number of hours, or with no expiration. Your own team’s access is never affected.

15. Scheduling (plan-gated)

Open an App and click Schedule.

Frequency — Daily, Weekly (pick the day), or Monthly (pick the day of the month, 1–28 so every month fires).
Time and Timezone — your choice, not the server’s.
Label — optional, e.g. “Monday morning refresh”.
Each schedule can be enabled or disabled without deleting it, and the list shows the next run.

Scheduled runs appear in History with a Scheduled badge and email whoever your notification policy covers.

Scheduled runs never touch the web app, so the worker is the authority on limits and gates for them. A scheduled write-enabled run that no longer satisfies §7.1 is refused, not downgraded.

From a completed report, click Share and enter a recipient’s email address. Netridium creates a tokenized link and emails it. The recipient must sign in (or sign up) as that address to view it, and the link always opens an access-controlled viewer — never a raw file.

You choose whether clickable source-system links are shown in the shared view. A share can only show links if the App itself does. For a spreadsheet you have filtered or sorted, Start them on my current view opens the report for the recipient the way you had it; they can change the filters from there.

A dashboard shares the same way: open it and click Share. The recipient gets one link showing every card at once, in the dashboard’s own layout.

What they see is frozen at the moment you share it. A dashboard card normally shows its app’s latest result, but a share does not follow along — the recipient sees the results you were looking at when you sent the link, and runs after that don’t appear in their copy. Share again to send the newer numbers. The dialog lists every card and the date of the result it will carry, so you can see what you’re sending before you send it; a card with no result yet is listed as such, and a dashboard where nothing has run can’t be shared at all.

Two limits worth knowing. A share only ever carries results you can see — a card driven by someone else’s private run goes out empty rather than exposing it. And cards are re-checked against the recipient’s own permissions when they open the link: a card whose App their role can’t see shows as unavailable, without naming it. So a dashboard link never gives anyone more than they’d have opening the dashboard themselves. There’s no per-card download in the shared view.

Who results can be shared with

Settings → Security → Sharing decides who your team may send a link to:

Setting	Who may receive a link
Only users with permission to that app (default)	Someone in this workspace whose role can already see that App
Any user	Anyone in this workspace, whatever their role can see
Anyone (inside or outside the organization)	Any email address, including people with no account here

Two things to know. It applies to admins too — the same person who can change the setting is bound by it, and every change is recorded in your audit log. And tightening it also closes links already sent: the rule is re-checked each time a recipient opens or downloads a shared report, so a link that no longer qualifies stops working rather than being grandfathered in.

Under the default, a report whose App has since been deleted cannot be shared at all — there is no longer an app to check a permission against. Refused attempts are recorded in the audit log alongside successful shares.

For a dashboard the rule is checked against the dashboard app, and each card is checked separately when the link is opened (see above), so a recipient never sees through a dashboard what they couldn’t see directly.

If your workspace is managed by a service provider, the Share dialog has a second half: Share report with your provider. One click puts that report in your firm’s Shared list, where their staff can find it without you sending an email.

It does not give them anything. Your provider’s staff can already open this workspace and read every report in it — that is what being managed means, and it is what Settings → Security → Service Provider Access governs. Sharing is a shortcut, not a key: it says “look at this one” and nothing more. The button that actually controls what they can see is the one on the Security tab, not this one.

Which is why the rules differ from an email share in two ways worth knowing:

The Sharing setting above does not apply. It decides who a report may be disclosed to, and your provider is not a new recipient — they could already read it.
If you have turned Service Provider Access off, you cannot share, and the dialog says so. There would be nothing to look at: the shared report would sit in a list they can’t open. Turn access back on first.

Turning access off later is safe and immediate: anything you had already shared leaves your provider’s list along with everything else, and comes back if you grant access again. You can also take a single report back at any time with Unshare — though again, that only removes it from the list.

Anyone who can share a report by email can share it with the provider: an admin, or the person who ran it. Both sharing and unsharing are recorded in your audit log.

A dashboard’s Share dialog has the same second half, Share dashboard with your provider, and anyone who can open the dashboard can use it. Unlike an email share of a dashboard, it is not a frozen copy: your provider opens the dashboard itself, in your workspace, and sees each card’s latest result. That gives them nothing new either — they could already open the dashboard and every report behind its cards. For the same reason it doesn’t need any card to have a result yet.

17. Moving Apps between workspaces

On the Apps page, tick the rows you want and click Export to write a portable JSON file (in Chromium browsers you get a native Save dialog; elsewhere it downloads). Import reads such a file into the current workspace.

Connectors are referenced by name and type, so on import they are matched to that workspace’s own connectors and anything missing is reported back for you to wire up. This is the mechanism consultants and MSPs use to build once and deliver to many.

Every exported app carries a stable id, which is what lets you import an updated version of something you already have — including an app exported from another system, or written by hand outside the portal. Import always shows you what it would do first:

An app you don’t have yet is created.
An app you already have is left alone unless you tick Replace. Replacing updates it in place, so its schedules, role grants, favourites and run history all survive — the app keeps its identity rather than becoming a second copy.
An app with no id is always treated as new. Older export files have no ids, so re-importing one creates copies; the list shows you that before you commit.

Two changes are never applied quietly, because neither can be undone by re-running anything:

Allow Updates changing — an app gaining (or losing) the ability to create, update and delete records in your connected systems.
A run limit being raised — a higher cost, duration or update ceiling, including an app’s own limit being dropped in favour of the workspace’s.

Both are spelled out in the import list and need your confirmation. A LogicScript in the file that updates another system but arrives with Allow updates off is skipped, with the line that updates named (§7.1).

18. Apps published by your service provider

If your workspace is managed by a service provider, some Apps may arrive from their catalog. These carry a Managed badge in the list, and a banner in the editor naming the provider and the version.

A managed app can’t be edited here — it is kept up to date by them, and the lock is enforced in the database, not just in the UI. If you need to change one, Detach it: that keeps the app exactly as it is and hands it to you, after which you can edit it freely — but it stops receiving their updates.

19. Audit and governance

Audit Log (admin-only) records the standard events in this workspace, newest first — who ran what against which data, every connector write, and every admin change. Search it, filter by date range, and download CSV for your own records.

The controls behind it:

Workspace isolation. Every workspace’s data is isolated at the database level (row-level security); nothing crosses between them.
Encryption at rest. Connector credentials and AI keys are encrypted (AES-256-GCM) and are never returned to the browser.
Read-only by default. Writes need all three gates plus their preconditions (§7).
Contained execution. A LogicScript is a restricted language that Netridium itself runs: it has no file, network or library access, and it reaches your systems only through the connector calls written in it. Credentials are held by the platform, attached per call, and dropped when the run ends.
No AI keys in users’ hands. The product promise is AI results, not AI keys — a run cannot exfiltrate a connector credential or reach a system you haven’t authorized.

20. Plan, billing, and closing the account

20.1 Account

Settings → Account carries the subscription lifecycle:

Subscription — status, plan, and trial end date. Convert to paid now, Cancel subscription, or Resume subscription.
Plan & add-ons — switch plan, adjust Admin (builder) seats and Run (viewer) seats, and manage add-ons. Changes take effect once Stripe confirms them, so expect a brief “pending confirmation”.
Workspace membership — how many admins (builders) and how many runners (viewers) the workspace has.

Settings → Billing holds the billing contact email, the card billed for the subscription (add or replace it there), usage credits, and your Anthropic key.

20.2 Closing the workspace

Settings → Account → Close account.

You pick a reason and type the workspace name to confirm. Closing affects everyone in the workspace, so it is deliberately hard to do by accident.
Your subscription is cancelled at the end of the current billing period. Nothing changes until then — apps, schedules, and connectors keep working.
On that date the workspace closes and no one can sign in.
Changed your mind? Keep my account on the same card restores everything, any time before the close date.
Data is retained for a limited period afterwards, so contact support if you need the account reopened or a final export.

Only your own admins can close the workspace — your service provider cannot do it for you. This is different from Cancel subscription on the same page, which only stops billing and leaves the workspace open.

20.3 Demo and trial workspaces

A Demo or Trial badge in the header tells you the workspace isn’t a normal production one. In a Demo workspace, non-admins get a see-everything, change-nothing experience: every page opens but every save, add, delete, and run control is inert, and Users and the Audit Log are blocked outright because the demo workspace is shared. Neither demo nor trial workspaces can buy usage credits.

21. Builder best practices

Be explicit about the output. “Return an Excel sheet with columns X, Y, Z” gives consistent results run to run. Vague prompts give variable ones.
Start read-only. Turn on writes only when an app truly needs them, on the one connector that needs them, and set the ceilings §7.1 requires before you do.
Use inputs instead of hard-coding, so one app serves many cases.
Match the type to the job. A Prompt for something you can describe; a LogicScript when the steps and the numbers must be exact.
Match the tier to the job. Most work is Sonnet. Reserve Fable and Opus for the analysis that needs them, and use Haiku for high-volume extraction.
Turn on Batch for anything nobody is waiting on — roughly half the cost.
Name and folder clearly. Your users browse by name; folders are what keep a catalog of fifty apps navigable.
Test, then publish. Run it yourself, confirm the result, then grant Run.
Set a workspace default run limit early, before anyone else can start runs.

22. Quick reference

Task	Where
Build / edit / run an App	Apps
See every run	History
See spend and volume	Usage
Connect a system	Settings → Connectors
Let an app write data	App → Options → Allow updates and connector → Allow Updates
Schedule an app	App → Schedule
Grant access to an app	Roles
Invite / approve / deactivate people	Users
Company details, notifications	Settings → General
Cap a single run	Settings → Run limits
Cap a month’s spend	Settings → Budgets
Attribute usage internally	Settings → Cost Centers
Require two-step verification	Settings → Security
Identity provider sign-in	Settings → Single sign-on
Control provider access to your workspace	Settings → Security
Your own Anthropic key, billing contact, card on file, credits	Settings → Billing
Subscription, plan, seats	Settings → Account
Close the workspace	Settings → Account → Close account
Your password / two-step / email	Profile