Quick actions reference

Module cards, list cards, quick starts, and business module nav

Growth Hub is a cross-module command center. It must route users into CRM, Contract Hub, Document Sign, or PDF Studio without owning their records.

Governance tab

Used to explain RBAC, delegated access, audit, and evidence posture across modules.

Growth Hub action search, category filters, API/MCP details, validation notes, and route links

Makes Growth Hub operable as a command center: users can search dashboard, module launcher, lists, governance, analytics, and optional handoff actions without guessing which module owns the work.

Growth Hub summary cards, object search, and evidence export controls

Closes the Growth Hub command-center readback routes that operators use to inspect summary posture, searchable CRM/PDF/signing objects, and retained evidence bundles.

Growth Hub action catalog buttons and guarded recommendation drawers

Groups the cross-module next-best-action endpoints for stale deals, at-risk accounts, signer reminders, and PDF risk review so action docs track the live controls instead of leaving route drift hidden.

Account name field and Create button

Creates a native Atlas account record without requiring Salesforce or HubSpot.

Account picker, deal name, amount, expected close picker, and Create button

Deal creation is intentionally customer-scoped. PDF, signing, and contract links stay optional.

Account/deal pickers, activity note, and Log button

Activity logs attach to CRM context only and do not create PDF/signing side effects.

Import and Merge tabs

Bulk CRM changes must keep conflict review and rollback visible before destructive decisions.

CRM action search, category filters, API/MCP details, validation notes, and route links

Makes Sales CRM operable as a standalone workspace: users can search account, contact, deal, activity, forecast, import, merge, rollback, and optional handoff actions without knowing the page layout.

Forecast command center and Monte Carlo forecast action

Maps the v2 sales forecast endpoint that supports the CRM forecast command center.

Packet builder, lifecycle header, obligation ledger, and approval panels

Contract Hub can reference CRM, signing, and PDF records, but contract lifecycle is standalone.

Contract action search, category filters, API/MCP details, validation notes, and route links

Makes Contract Hub operable as a standalone lifecycle workspace: users can search packets, renewals, approvals, obligations, redlines, remediation, evidence, and optional handoffs without depending on CRM navigation.

Envelope form, recipient fields, routing controls, send/reminder buttons

Document Sign owns signer routing and audit evidence, not PDF editing.

Signing action search, category filters, API/MCP details, validation notes, and route links

Makes Document Sign operable as a standalone signing workspace: users can search envelopes, recipients, sessions, templates, fields, lifecycle, evidence, and optional handoffs without using Sales CRM.

Public signing view, decline/sign buttons, and certificate download

Maps the public signing token route family, including ceremony reads, sign/decline decisions, and completion certificate download.

PDF name, page count, risk flag, source upload, and optional connected workflow expander

This is the key standalone PDF boundary: no customer, deal, contract, or signing context is required.

Document workbench operation buttons

Covers organize, edit, annotate, OCR, extract, redact, protect, compare, convert, compress, sign, and export workflows.

PDF tool search, category filters, API/MCP details, and route links

Makes PDF Studio operable like a standalone PDF website: users can search for merge, split, OCR, redact, forms, stamps, compression, export, and evidence without knowing where Atlas placed the button.

Preview source, comments, download source/artifacts, split packages, and evidence rows

Export remains file-first; optional signing/contract/CRM handoff is an explicit navigation decision.

Stamp asset library, template editor, thumbnail actions, and bulk cleanup preview

Covers the PDF Studio stamp-library route family: upload tickets, versions, thumbnails, archive/restore, template CRUD, and bulk annotation cleanup.

PDF security readiness panel and sanitizer operation status

Keeps PDF security and redaction readiness routes visible in the action registry while treating provider callback execution as a guarded integration boundary.

REST API with the pdf:write scope taking a base64 PDF; the Fill and edit forms screen fills forms in the browser instead

These routes read every form field with its type, options, and value, export the same data as an FDF file, fill a form from JSON values or an FDF file, and flatten a form so its fields become fixed content. Import and flatten answer JSON that includes the filled PDF and a report of any values that were ignored and why. Field names and values are never logged.

PDF editor Ask AI panel: summarize button, extract tables button, question field with ask button, and a streamed answer

A person opens the Ask AI panel in the PDF editor to get a summary, an answer to a question, or the document's tables as text, each grounded only in the file and streamed as server-sent events. The routes need the model provider to be configured; without it they say that document questions are unavailable. When the person leaves, the stream stops so no further model work is spent.

PDF Studio conversion tools (for example PDF to Word): file drop, use URL, convert, live progress, cancel, keep result, and download

A person picks a file, the server issues an upload ticket for object storage, the browser uploads the file directly, and then the job starts, streams progress, and offers a time-limited download link. Reading needs the PDF Studio view permission and pdf:read, creating and starting need export and pdf:write, cancel and keep need update, and delete needs the delete permission. Results are removed 24 hours after they are created unless kept, and the routes answer 503 when object storage is not configured.

Bates numbering screen: file picker, prefix, suffix, start number, digits, position, font size, number preview, and stamp button

A person stamps gapless, sequential Bates numbers across every page of a document on the server, so the run is deterministic and citable, and downloads the stamped PDF. The route refuses invalid settings and unreadable files with 422 and an oversized file with 413. The prefix and the file content are never logged.

REST API with the pdf:write scope taking base64 PDFs

These routes extract page ranges as a new PDF, split one PDF into many, produce a structured text comparison of two PDFs, verify the digital signatures in a PDF, and sign or certify a PDF when the server has a signing identity. Invalid page ranges, broken files, and bad signatures are refused with 422 and a message for the person. No filename, page text, signer name, or signing reason is logged.

Payroll runs page, draft/approve buttons, payslip detail drawer

Covers payroll run lifecycle (draft, calc, approve, post) and individual payslip read/release endpoints under /v1/hr/payroll.

Hiring pipeline board, candidate drawers, offer composer

Hiring controllers under /v1/hr/hiring cover requisitions, candidates, stages, interviews, and offers across the recruitment lifecycle.

Employee directory, profile drawer, status toggles

Directory endpoints under /v1/hr/employees cover read, search, profile updates, and lifecycle status changes for staff records.

Leave request form, approver queue, balance summaries

Leave endpoints under /v1/hr/leave cover request submission, approval, balance lookup, and audit-trail surfaces.

Cycle calendar, review forms, feedback drawer

Performance endpoints under /v1/hr/performance cover review cycles, peer feedback, manager comments, and calibration steps.

Reimbursement composer, receipts uploader, approver queue

Reimbursement endpoints under /v1/hr/reimbursements cover submission, receipt upload, approver workflow, and payout linkage.

Ticket composer, message thread, status tracker

HR Helpdesk endpoints under /v1/hr/tickets cover ticket creation, replies, status updates, and admin assignment.

HR admin console, policies tab, config panels

HR admin endpoints under /v1/hr/admin cover policy CRUD, working-hour rules, leave catalog, and other tenant-wide HR config.

Projects list, project board, plan view, settings drawer

Projects controllers under /v1/projects (and legacy /projects) cover project CRUD, plan/board reads, status changes, member assignment, and document linkage.

Task list, planner, detail drawer, scheduler quick actions

Task endpoints under /v1/tasks, /tasks/{id}, /tasks/{taskId}, and /tasks/auto-schedule cover the full task lifecycle including dependencies and planner.

CRM list, deal pipeline, contact drawer, account profile

CRM endpoints under /v1/crm cover the core accounts/deals/contacts/activities CRUD that powers Sales CRM and Growth Hub flows.

Contracts list, contract drawer, clause library, evidence panel

Contracts endpoints under /v1/contracts cover the native Contract Hub surface: contract CRUD, clauses, parties, evidence, and lifecycle transitions.

Integration directory, connector cards, OAuth callbacks

Integrations and connector endpoints under /v1/integrations and /v1/connectors cover the full third-party connector lifecycle (install, configure, sync, remove), with live MCP readback/OAuth-start coverage, admin-gated connection-targeted test/disconnect tools, and Linear, Microsoft 365 and Granola provider actions. Secret-bearing credential save remains REST-only until the MCP secret-input policy is formalized, which is why the Granola credential route has no tool.

Inbound webhook registered with WhatsApp per workspace; the platform calls it with signed delivery receipts and replies

WhatsApp calls this route once to verify the subscription and then for every delivery receipt and inbound reply, so the workspace can mark sent messages delivered, read, or failed and record opt-in and opt-out replies. The route is public because the caller holds no Atlas credential, so the signature over the raw body is the whole of the authentication. Receipts for message ids the workspace does not know are ignored.

Profile page, preferences, identity dashboard

Self-service endpoints under /v1/me and /profile/me cover the signed-in user's profile, preferences, sessions, and identity-affecting reads.

Admin console, settings panel, audit drawer

Tenant admin endpoints under /v1/admin, /v1/account, and /v1/settings cover settings, account profile, billing-adjacent reads, and audit history.

Settings, Reference series: per record kind editor for prefix, suffix, separator, padding, year, month, reset cadence, and next number, with live preview, save, and discard

An administrator shapes the readable reference numbers that records receive, previews sample references before saving, and saves the series. Listing and previewing need the team view permission, while saving needs the team admin permission and an owner or administrator role. The route is not tied to any premium module, because every workspace has records that need a reference.

Meetings calendar, room drawer, transcript panel

Meeting endpoints under /meetings/{id} cover the meeting lifecycle: details, participants, recordings, and transcripts.

Wiki tree, page editor, version history

Wiki endpoints under /wiki/pages cover page CRUD, hierarchy moves, version snapshots, and collaborative cursors.

REST API and agent tools with a token that carries the wiki:read scope

This route searches the workspace wiki for pages whose title or body contains the query text, ignoring case, newest updated first. It reads only the caller's workspace and never returns deleted or archived pages. It changes nothing.

Blog composer, publish queue, audit drawer

Blog endpoints under /blog/posts cover post drafts, publishing, scheduling, and revision history for tenant-owned content.

Goals tree, key-result editor, check-in drawer

Goals endpoints under /goals/{id} cover goal lifecycle, key-result updates, check-ins, and reporting rollups.

REST API with a personal access token that carries the goals:read, goals:write, or goals:delete scope

These public routes list, read, create, update, and delete objectives and key results with rolled-up progress, and return the rollup tree under a goal. Reading needs goals:read, changes need goals:write, and deleting needs goals:delete. Every create, update, and delete is recorded in the audit log. The Goals screen uses the session routes of the same service.

Marketplace directory, app drawer, install button

Marketplace endpoints under /v1/marketplace cover app directory listing, app detail, install, and lifecycle audit hooks.

Compliance dashboard, audit drawer, evidence panel

Compliance endpoints under /v1/compliance and /v1/privacy cover posture summaries, audit history, DSAR workflow, and evidence reads.

Webhook registry, delivery log, retry drawer

Webhook endpoints under /v1/webhooks and /v2/webhooks cover endpoint registration, delivery log, signing key rotation, and replay actions.

Access console, role editor, ACL inspector

Access endpoints under /v1/access and /custom-roles cover access snapshots, module enablement, invites, member roles, grants, suite changes, provisioning, custom-role authoring, and access review reporting.

Settings, Security, IP allowlist: add entry form with address or CIDR block and label, entry list, and remove button on each

An owner or administrator lists, adds, and removes the network addresses allowed to reach the workspace. Once at least one entry is enabled, every request from an address outside the list is refused with 403, including requests made with tokens; with no enabled entries access is open. Every change is written to the audit log.

AI providers console, model registry, run inspector

AI platform endpoints under /v1/ai and /v1/ai-providers cover provider registry, model catalog, run history, and prompt template administration.

AI observability provider table, summary cards, and trace explorer

Closes the AI observability route family for provider status, aggregate summaries, and trace readback.

Ask Atlas bar, natural language capture card, summarize drawer, and recommendations on the tasks, projects, and dashboard screens; REST API with the intelligence scopes

These routes run Atlas's own models on the server to rank candidates by meaning, recommend next items from interactions, extract dates and entities from a sentence, summarize text, and generate text that can be constrained to a JSON schema. Each call is scoped to the caller's workspace, traced, and metered against its credits. They are refused when the workspace lacks the intelligence entitlement or has used up its credits.

OAuth consent screens, app dashboards, scope grants

OAuth platform endpoints under /v2/oauth cover authorization, token, refresh, revoke, introspect, and discovery for tenant-managed apps.

Settings, Connected apps: assistant apps card listing each approved app with its scopes and dates, and an end access button

A signed-in person sees the apps and AI assistants they approved through Sign in with Atlas, with the scopes granted, when they first approved, and when the app last received a token, and can end any one of them. Both routes are limited to the caller's own grants in their own workspace and need the pats:manage scope on a session. The revoke route answers with the number of tokens it revoked, which is zero for an app the caller never approved.

SCIM connector, directory sync console, audit drawer

SCIM endpoints under /scim/v2 implement RFC 7644 user/group provisioning, group membership patches, and audit reads for enterprise IdPs.

Connector list, install drawer, status badges

Legacy connector endpoints under /v1/connectors cover install/uninstall, status pings, config reads, and now live MCP-backed catalog/OAuth-start/event readback, connection-targeted test/disconnect, plus Linear, Microsoft 365 and Granola provider operations.

Privacy console, DSAR queue, consent drawer

Privacy endpoints under /v1/privacy cover data-subject access requests, consent log reads, retention policy queries, and right-to-erasure workflows.

Settings, Data retention: one row per module with a days field or keep forever, and a save button

An owner or administrator sees one retention row for every module that can be purged and sets how many days its records are kept, or keeps them forever. Every change is written to the audit log and applies only to the caller's workspace. Records under an active legal hold are not purged.

Settings, Data retention: legal hold form with name, reason, and scope, a list of holds, and a release button on each

An owner or administrator places a legal hold on the whole workspace, one module, or one record so that retention purges skip it, and later releases it. Releasing records who released the hold and when, and every change is written to the audit log. The routes read and change only the caller's workspace.

Automation editor, run history, trigger drawer

Automation script endpoints under /automations/scripts cover script CRUD, manual triggers, run history, and trigger schedules.

REST API with a personal access token that carries the automations:read or automations:write scope

These public routes create, edit, enable, disable, run, and delete the workspace's audit-event automation rules, and read their run and version history, through the same service as the Settings Automations screen. Reading needs automations:read and every change needs automations:write, with the public API rate limits and Idempotency-Key replay applied. A manual run answers 202 with the run outcome, and a revert is forward only: it applies the older snapshot as a new version rather than rewriting history. Rules are scoped to the caller's workspace, and an id from another workspace answers 404.

REST API with a personal access token that carries the automations:read or automations:write scope

These public routes create, read, update, deactivate, and run script automations, and read their run history, through the same service as the Scripts screen. Reading needs automations:read and every change needs automations:write. Creating a webhook-triggered script returns its webhook secret once, the run route queues a manual run and answers 202 with the run id, and DELETE deactivates the script rather than deleting it. The list returns every script automation in the caller's workspace, while the per-script routes enforce ownership.

Report scheduler, delivery log, email pipeline drawer

Reporting endpoints under /v1/report-deliveries, /v1/status, and /v1/email cover scheduled report fan-out, status posture, and email delivery telemetry.

Approvals queue, policy editor, run inspector

Agent governance endpoints under /agent-governance/approvals cover approval queue management, policy edits, and audit reads for agent decisions.

Appointment calendar, drawer, reschedule action

Appointment endpoints under /appointments/{id} cover appointment booking, reschedule, cancel, and confirmation flows.

Appointment drawer, reschedule flow, cancel/no-show/reminder actions

Captures the v1 appointment lifecycle route family used by the booking and scheduling surfaces.

Residency console, region pinning, evidence drawer

Data residency endpoints under /v1/data-residency cover tenant region pinning, residency posture, and migration evidence reads.

Envelope composer, signer drawer, evidence panel

eSign endpoints under /v1/esign cover envelope CRUD, signer order, status updates, evidence reads, and webhook callbacks for the Document Sign module.

HR console sub-tabs for onboarding, policies, probations, role changes, attendance, holidays, letters, departments, locations, performance, reports, statutory, exit interviews, documents, emergency contacts, employment records, org chart

HR operational endpoints cover onboarding workflows, policies, probations, role changes, attendance, holidays, letters, departments, locations, performance reviews, statutory reports, exit interviews, documents, emergency contacts, employment records, and org chart reads.

Login, signup, password reset, OAuth + SSO callback pages

Auth endpoints under /auth, /v1/auth, and /v1/oauth cover login, signup, password reset, OAuth providers, SSO callbacks, and session bootstrap.

Sign-in page: Sign in with a passkey button, and saved passkeys offered in the email field where the browser supports it

These public routes sign a person in with a passkey saved on their device. A successful sign-in returns the same session, and sets the same refresh cookie, as a password sign-in, and asks for no separate two-step code. The sign-in page remembers that the person last used a passkey.

Sign-in page: Email me a sign-in link, resend and change email; the link page at /auth/link with continue and cancel when the link is opened in another browser, and ask for a new link when it has expired

These public routes send a one-use sign-in link to an address and turn the opened link into a session, with the same refresh cookie a password sign-in sets. The request sets a short-lived cookie in the browser that asked, so a link opened there signs in at once and a link opened anywhere else asks the person to confirm first.

Notification bell, preferences panel, push subscription drawer

Notification endpoints under /notifications, /notification-preferences, /notification-prefs, /push and /v1/push cover the in-app feed, preference toggles, and push notification subscription lifecycle.

Calendar page, grid preferences toggles, availability drawer

Calendar endpoints under /calendar, /calendar-grid-preferences, /availability, and /auto-schedule cover the unified calendar view, event CRUD, grid preferences, availability windows, and auto-schedule planner.

REST API with a personal access token that carries the calendar:read or calendar:write scope

These public routes read and update the workspace calendar preferences, list configured providers and the caller's own connected calendars, disconnect one, read external events and tasks from those calendars, list public holidays, and push a task as an event to every connected calendar. Reading needs calendar:read and changes need calendar:write. Events, external tasks, and task sync return results only when the caller has connected a calendar, and task sync reports the outcome per provider. The calendar settings screen uses the session routes of the same service.

Command bar, saved views, search results page

Search endpoints under /search, /v1/search, /v1/unified-search, /v1/cross-tool-search, /frecency, /saved-views, and /task-saved-filters cover unified search, frecency ranking, saved views, and per-module filter persistence.

Onboarding wizard, checklist, tenant setup screens

Onboarding endpoints under /onboarding cover the new-user wizard, tenant bootstrap, initial admin assignment, and checklist progression reads.

Avatar stack, live cursor overlay, sync indicator

Presence endpoints under /presence, /live, /sync, and /share cover realtime presence broadcast, live cursors, sync channel reads, and ephemeral share links.

Feedback widget, inspiration panel, morning briefing card

Feedback and personalization endpoints under /v1/feedback, /inspiration, /morning-briefing, /digest, and /focus-coaching cover user feedback submission, daily inspiration, briefings, digests, and focus coaching prompts.

Onboarding page satisfaction widget: score buttons 0 to 10, optional comment, submit, skip comment, and close

A signed-in person rates Atlas from 0 to 10 and may add a comment, and the server stores the response against their workspace and user with a computed category. The route is self-service for the caller's own workspace and is refused when the workspace lacks the required module entitlement. It does not itself enforce the 90-day survey interval; the eligibility routes report that interval.

Onboarding page referral card: referral link, copy button, and share button with click, signup, and credit counts

A signed-in person reads the workspace referral code with its click count, signup count, and earned credit, and copies or shares a signup link that carries it. The route only reads, or creates the code once, for the caller's own workspace. It never exposes another workspace's code or totals.

REST API with the growth:read or growth:write scope; the growth-status routes accept a personal access token and agent tools

These routes record a quick positive, neutral, or negative feedback pulse, report whether the caller may answer the satisfaction survey yet, redeem another workspace's referral code, and read the referral summary and survey eligibility through the token-friendly growth-status surface. Every route is scoped to the caller's own user and workspace. A successful redemption credits the referring workspace once and is refused for self-referral or a repeat.

Support page form: subject, message, category, product area, priority, email, name, company, phone, optional attachment, and submit button

Anyone, including a signed-out visitor, opens a support request from the public support page or a help entry point. The route needs no credential, stores the request, and notifies the Atlas support team by email when email is configured. Reading, answering, and updating requests are separate routes restricted to Atlas staff.

Billing console, plan picker, rate-limit drawer

Billing endpoints under /v1/billing and /v1/rate-limit-tiers cover plan subscription, invoice reads, and rate-limit tier overrides.

Settings, Billing, checkout flow: coupon code field and apply button above the pay button

During checkout a person types a coupon code and the server prices the selected plan, cycle, modules, and currency, then reports whether the coupon applies and what it takes off. The route accepts only a signed-in session from an owner, administrator, or member who can view billing. It does not redeem the coupon; it only reports validity and the discount for the quoted order.

Read by the app shell to show or lock modules and features; callable with the profile:read scope

This route returns the effective entitlements of the caller's workspace: which modules and features its plan and any grants allow, and its limits. The web app uses it to hide or lock surfaces when the signed-in session does not already carry the entitlement set. It is a self-service route for the caller's own workspace and cannot read another workspace.

Inbound webhook called by the payment provider from its own servers; no Atlas credential, authenticated by its signature

The payment provider calls this route to report billing events for a workspace, and it is the only place where a paid plan or module is granted to a workspace. The route is public because the provider holds no Atlas credential, so the signature over the raw body is the whole of the authentication. Signatures, secrets, and payloads are never logged.

Plans page: tier, cycle, module, currency, and tax number selectors, plan recommender with team size and goals, live quote, and checkout button

Anyone, signed in or not, reads the effective plan catalog, gets a quote for a plan, cycle, modules, add-ons, and currency, and asks for a recommended plan from team size and goals. All price arithmetic happens on the server from one catalog, so the page and checkout never disagree about a price. The catalog is the built-in default unless Atlas staff have saved an override.

Status page, internal metrics dashboard

Observability endpoints under /health, /ready, /metrics, /observability, /v1/health, and /.well-known cover health probes, readiness gates, Prometheus metrics, and well-known discovery documents.

Public blog, public share links, marketing pages

Public endpoints under /public, /public-blog, and /public-shares cover marketing pages, public blog reads, and unauthenticated share token lookups for documents, dashboards, and previews.

Called by the browser extension popup and new tab page for the daily quote and wallpaper; shuffle=true asks for a fresh pick

This route returns the day's inspiration bundle, such as a quote and a wallpaper, from public sources, cached for several hours unless a shuffle is requested. It is an alias of the unprefixed inspiration route kept for browser extension builds that already call the /v1 path. It holds no workspace data and needs no sign-in.

Time entry drawer, workload view, focus timer

Time tracking endpoints under /time-entries, /workload, and /focus-sessions cover time entry CRUD, workload allocations, and focus session reads tied to the planner.

Time approval inbox, detail drawer, approve/reject buttons

Covers manager-facing time approval reads and approve/reject decisions.

REST API with a personal access token that carries the time:read, time:write, or time:delete scope

These public routes let a person list their time entries, log a completed entry, start and stop a timer, read the running timer, and edit or delete their own entries. Reading needs time:read, changes need time:write, and deleting needs time:delete. The duration is always computed on the server from the start and end times. The Time Tracking screen uses the session routes of the same service.

Form builder, attribute panel, formula editor, label picker

Forms engine endpoints under /forms, /field-policies, /custom-attributes, /formula-fields, and /labels cover form CRUD, submission, field policy management, custom attributes, formula fields, and labels across modules.

REST API with a personal access token that carries the forms:read or forms:write scope

These public routes list, create, edit, and delete intake forms that turn each submission into a task on a project, export up to 1,000 submissions as CSV, and request or record an approval on a task. Reading needs forms:read and every change needs forms:write. The approval routes set the task's approval state to pending, approved, or rejected and record who decided; they apply no role or state check beyond the scope. Public form schema and submission routes are not part of this surface.

Booking page editor, meeting type drawer, host availability matrix

Booking engine endpoints under /booking-pages, /booking-meeting-types, /booking-webhooks, /booking-blackouts, /booking-page-hosts, /booking-questions, /booking-analytics, and /scheduling-rules cover booking page CRUD, meeting types, blackout windows, webhook fan-out, host configuration, intake questions, analytics, and scheduling rules.

Public booking page meeting-type selector and question form

Covers unauthenticated booking metadata reads used by public booking pages before an appointment is created.

Release notes page, changelog widget

Release notes endpoints under /release-notes cover the public changelog, in-app release notes panel, and admin authoring surface.

Customer changelog page, entry detail, and RSS subscription

Covers the public changelog list, slug detail, and RSS feed routes added for customer-facing release notes.

Workspace switcher, team admin, tenant settings, branding panel

Workspace endpoints under /workspaces, /v1/workspaces, /teams, /tenants, /v1/tenant, /v1/tenants, and /v1/tenant-branding cover workspace CRUD, team admin, tenant settings, and branding management.

Profile page, theme picker, habits tracker, daily notes panel

Profile and personal endpoints under /profile, /me, /user-theme, /habits, /daily-notes, and /journal-reviews cover the signed-in user profile, theme preferences, habits tracker, daily notes, and journal reviews.

SSO admin console, IdP metadata upload

SSO endpoints under /v1/sso cover SAML/OIDC configuration, IdP metadata upload, JIT provisioning, and SSO callback handling.

Sign-in page: Use single sign-on button, work email field, continue, back to sign in, and the return page that finishes the sign-in

This public route finds the workspace whose verified email domain serves a work address and returns where its SAML sign-in starts; the sign-in page then sends the person there, and the identity provider returns them to /auth/sso to finish. It is for people whose workspace signs them in through its own identity provider.

Settings, Security, single sign-on domains card: domain field and add button, the TXT record name and value with copy buttons, verify now, and remove

An owner or administrator claims the email domains their people sign in with and proves the workspace owns each one with a DNS record. Only a verified domain is used by single sign-on discovery, because an unproven domain would let one workspace send another company's people to its own identity provider. The workspace is always the session's own, adding and verifying are written to the audit log, and a removed domain stops matching at once.

Two-factor enrollment screen, recovery codes drawer

Two-factor endpoints under /v1/two-factor cover TOTP enrollment, challenge verification, and recovery code management for end users.

Settings, Security, Passkeys card: add a passkey, confirm with your password or an emailed code, name it, then rename or remove each passkey in the list

These routes let a signed-in person manage their own passkeys from security settings: list them with when each was added and last used, add one after proving it is them again, rename one, and remove one. Adding a passkey adds a way into the account, which is why it needs a fresh password or emailed code rather than the age of the session. A passkey signs a person in without a separate two-step code, because it already proves possession of the device and the person's verification on it.

Sessions panel in profile/security settings

Session endpoints under /v1/sessions cover active session listing, single-session revoke, and bulk revoke flows tied to the security console.

Tokens page in profile/security settings

Token endpoints under /v1/pats and /v1/access-tokens cover personal access token creation, rotation, revoke, scope edit, and listing.

Audit log explorer, activity feed widget

Audit endpoints under /v1/audit-log, /audit-events, and /activity-feed cover audit log search, activity feed reads, and exportable audit event streams for compliance reviews.

Settings, Security, SIEM export: destination form with format, secret token, enabled switch, and event filter; save and remove buttons; delivery log with load more

An owner or administrator configures where the workspace audit feed is sent, in which format, and which actions are included, then reads the log of delivery attempts. Reads need the audit log view permission and the workspace:read scope; saving and removing need the audit log export permission and the workspace:manage scope, and every change is written to the audit log. The secret token is never returned, only whether one is set, and each workspace has at most one configuration.

Analytics dashboards, A/B test console

Analytics endpoints under /v1/analytics and /v1/email-ab-tests cover aggregate analytics queries, dashboards, and A/B test allocation/reads.

Reports console, email template editor, SEO admin

Reports and editorial endpoints under /v1/reports, /v1/email-templates, /v1/seo, and /v1/themes cover scheduled reports, email template authoring, SEO admin, and theme management.

Public dashboard sharing controls and revoke action

Covers public dashboard listing, creation, and token revocation for shareable reporting surfaces.

REST API with a personal access token that carries the reports:read scope

These public routes let a token list, read, run, and export saved report definitions and dashboards, and run ad hoc aggregation queries, for business intelligence and agent callers. Every query runs scoped to the caller's workspace, and the CSV export returns a saved report's result as a file attachment. The POST routes only run queries, so they stay available in a read-only view-as session. Creating and editing reports and dashboards is not offered here.

REST API with a personal access token that carries the reports:read or reports:write scope, returning JSON or CSV

These routes let BI tools and scheduled extract jobs discover the reporting datasets, run an ad hoc aggregation, or pull a saved report, as JSON or as a CSV attachment. Every route needs the reports export permission; reading datasets and saved reports needs the reports:read scope, and running an ad hoc query needs reports:write. A saved report from another workspace is reported as not found.

Webhook endpoints console, delivery log

Webhook endpoints under /v1/webhook-endpoints, /v1/webhook-deliveries, and /v1/watch cover webhook configuration, delivery log inspection, and watch subscriptions used by external integrators.

Integration directory, inbound email config, slack admin, AI model picker

Integration extras under /integrations, /inbound-email, /v1/slack, /v1/ai-models, and /v1/voice cover inbound email parsing, Slack admin, AI model selection, and voice transcription endpoints.

Task drawer, templates picker, relations panel

Task platform extras under /tasks, /task-templates, /task-relations, /template-library, /templates, and /comments cover task templates, relations between tasks, the cross-module template library, and comments across resources.

Bulk action bar, label picker, and comment composer

Maps the shared bulk operation endpoints that power multi-select task, label, and comment workflows.

My Work focus coaching panel and suggestion cards

Maps the focus coaching suggestion endpoint used by My Work and planning guidance surfaces.

Task type settings list and type detail drawer

Covers global and project-scoped task type catalog/list/key/id readback endpoints.

Project drawer subtabs and board configuration

Project platform extras under /projects, /project-risks, /v1/project-risks, /project-milestones, /project-status-updates, /project-dependencies, /v1/project-dependencies, /project-stakeholders, /initiatives, /portfolios, /cycles, and /board-columns cover risks, milestones, status updates, dependencies, stakeholders, initiatives, portfolios, cycles, and board column configuration.

Goals dashboard, goal drawer

Goals platform endpoints under /goals cover the full goal catalog: CRUD, progress updates, alignment with cycles, and team scoping.

Meetings list, meeting detail, insights drawer

Meetings endpoints under /meetings, /v1/meetings, /v1/meeting-insights, and /v1/video-attachments cover meeting CRUD, AI-powered insights, transcripts, and video attachment uploads.

Wiki editor, page tree, collaboration cursors

Wiki platform endpoints under /v1/wiki, /v1/wiki-presence, and /v1/wiki-collab cover wiki page CRUD, realtime presence, and collaborative edit broadcast.

Blog editor, blog list

Blog endpoints under /blog cover internal blog post authoring, publishing, and reads across the tenant.

Automations console, run history, script editor

Automations platform endpoints under /automations cover script authoring, trigger configuration, run history, and operational reads for the no-code automation surface.

Custom roles console

Custom roles endpoints under /custom-roles cover role definition CRUD, permission scoping, and assignment management across modules.

Undo toast, trash explorer, quick links menu, keyboard shortcuts dialog

Undo and recovery endpoints under /undo-entries, /v1/trash, /quick-links, and /v1/shortcuts cover undo stack reads, trash recovery, quick links, and keyboard shortcut definitions.

Drift feed widget, mute drawer

Inbox and scheduler drift endpoints under /today-scheduler-drift-feed, /scheduler-drift-mute-state, and /appointments cover the today drift feed, mute state controls, and appointment notifications shown on the planner.

REST API and agent tools with a personal access token that carries the inbox:read or inbox:write scope

These routes let a token or agent read the caller's notification inbox with filters, cursor paging, and an unread count, mark one notification read or unread, and mark everything read. Every route is scoped to the calling person, so nobody can read or change another person's notifications. Reading needs inbox:read and the three mark routes need inbox:write.

PDF studio editor, OCR drawer, convert pipeline

PDF platform endpoints under /v1/pdf, /v1/pdf-studio, /v1/pdf-secure, /v1/pdf-convert, and /v1/pdf-ocr cover PDF tooling APIs, secure share links, conversion pipelines, and OCR job orchestration.

Docs portal, Postman download buttons

Docs platform endpoints under /v1/docs, /v1/postman-environment.json, and /v1/postman.json cover generated documentation portals, Postman environment exports, and OpenAPI reference artifacts.

Extension error console (internal)

Extension error endpoints under /v1/extension-errors cover browser extension crash and exception ingest, replay, and internal review for extension stability monitoring.

Called by the Atlas browser extension, which posts each buffered analytics event with the signed-in person's credential

The browser extension sends each product analytics event here, and the server records it against the caller's workspace and user and answers 204 without a body. Events are kept in a bounded in-process buffer and written as one structured log line each, not stored in the database. Malformed or oversized events are refused with a validation error.

Engagement register: sort control, view switch, load more button, retry on a failed read, and the engagement link that opens the engagement workspace

These routes list the engagements in the workspace page by page and return one engagement record. They require a signed-in OWNER, ADMIN or MEMBER of a workspace whose plan includes Client Delivery, view access to the client-delivery module, and the delivery:read scope for a token; a portal guest is refused. Engagements walled off by an information barrier, or marked restricted when the caller holds no access grant, are left out of the list and answer 404 on the single read, exactly as an id that never existed.

REST API and agent tools with a personal access token that carries the delivery:read or delivery:write scope

Summary returns portfolio counts by status and the number at risk, my returns up to 100 live engagements where the caller is partner, manager, QA reviewer or PMO lead, PATCH edits the engagement record, and DELETE soft deletes it. All four need a workspace whose plan includes Client Delivery and an OWNER, ADMIN or MEMBER role: reads need view access and delivery:read, PATCH needs update access and delivery:write, and DELETE needs delete access, delivery:write and the OWNER or ADMIN role. Restricting an engagement or lifting its restriction also needs the OWNER or ADMIN role, because it changes who can read the record. Engagements hidden by an information barrier or restricted access are excluded from the counts and from my, and a write to one answers 404, the same answer as an id from another workspace.

New engagement wizard: client, commercials, team, playbook and review steps, the playbook chooser, and the create button

The first route creates an engagement record for a client account, audits it and adds it to search; the second copies a playbook (the workspace copy when one exists, otherwise the built-in) into the new engagement's phases, workstreams, deliverables, responsibility matrix, RAID starters, meetings, information requests, closure items and checks. Both need a workspace whose plan includes Client Delivery and an OWNER, ADMIN or MEMBER role with delivery:write; creating needs create access and applying a playbook needs admin access on the client-delivery module, because it writes across many registers with no undo. Applying refuses an engagement that already holds work, and an engagement hidden by an information barrier or restricted access answers 404.

Engagement workspace lifecycle panel: status move buttons with a reason, RAG rating form, archive with confirmation, and restore

These routes move an engagement between lifecycle statuses, record a RAG rating with its reason and author, archive an engagement out of the register and search, and restore it. They need a workspace whose plan includes Client Delivery, an OWNER, ADMIN or MEMBER role, update access on the client-delivery module and the delivery:write scope. Every write is audited, closing an engagement records a separate closed event, and an engagement hidden by an information barrier or restricted access answers 404.

Engagement workspace closure tab: readiness banner with blockers and warnings, and the reopen panel with a required reason

Readiness tells a partner whether an engagement may close today and lists each blocker and warning; reopen puts a closed engagement back into closure. Both need a workspace whose plan includes Client Delivery and an OWNER, ADMIN or MEMBER role; readiness needs view access and delivery:read, and reopen needs admin access, delivery:write and the OWNER or ADMIN role. An engagement hidden by an information barrier or restricted access answers 404 before anything is read.

Playbook library and editor: category filter and search, new playbook form, customise, collection editors for each section, save, reset to built-in, and remove with confirmation

These routes read the playbook library (the built-in playbooks merged with this workspace's own and customised copies), write a playbook from nothing, take an editable copy of a built-in, edit its fields and collections, reset a copy to the built-in, and remove a playbook the workspace wrote. Reads need view access and delivery:read; every write needs admin access on the client-delivery module, delivery:write and the OWNER or ADMIN role, because a playbook shapes every engagement started from it. All routes need a workspace whose plan includes Client Delivery, and engagements already started are not changed.

Delivery home tiles and recent engagements, and the firm-wide RAID, meetings, requests, actions, approvals and exports screens with a link to each engagement

These read-only routes gather open work across all engagements in the workspace: the portfolio counters, open RAID items, meetings, information requests, follow-up actions, change requests awaiting approval, and export jobs. They need a workspace whose plan includes Client Delivery, an OWNER, ADMIN or MEMBER role, view access on the client-delivery module and the delivery:read scope; a portal guest is refused. Rows of engagements the caller may not see are excluded in the query, so they neither appear nor count. They accept no parameters and change nothing.

Engagement workspace people tab: portal invitations panel with a revoke button on each invitation

This route revokes a portal invitation so its token can no longer be accepted, and records an audit entry the first time. It needs a workspace whose plan includes Client Delivery, an OWNER, ADMIN or MEMBER role, update access on the client-delivery module and the delivery:write scope. A token issued by another workspace, or one for an engagement the caller may not see, answers 404 without saying which.

Delivery settings: a switch, lead days field and reset button for each follow-up rule, and the reporting officers picker with a save button

These routes read and change the firm-wide follow-up rules (which reminders run and how many days ahead) and the list of appointed money laundering reporting officers. Reads are open to an OWNER, ADMIN or MEMBER with view access on the client-delivery module and delivery:read; writes need admin access, delivery:write and the OWNER or ADMIN role, because turning off a rule or appointing an officer is an administrative decision. A portal guest is refused, and each write is recorded in the audit log.

Engagement workspace follow-ups tab: rules toggle, a switch and reset button for each rule on this engagement

The read returns each follow-up rule as it applies to one engagement, combining the firm setting with that engagement's overrides; the write changes those overrides. Reads need an OWNER, ADMIN or MEMBER role with view access and delivery:read; the write needs admin access, delivery:write and the OWNER or ADMIN role. An engagement the caller cannot see answers 404 before its configuration is read.

Status report composer: the cadence choice, prefilled from the firm setting, and its read failure notice

This read-only route returns how often the firm reports and on which day, so the status report composer proposes the right period. It needs an OWNER, ADMIN or MEMBER role, view access on the client-delivery module and delivery:read; a portal guest is refused. The cadence is firm-wide, and no engagement-level override exists.

REST API and agent tools with a personal access token that carries the delivery:read scope

This read-only route returns the closed sets used by Client Delivery follow-ups, so an integration or agent tool reads them instead of keeping its own copy. It needs an OWNER, ADMIN or MEMBER role, view access on the client-delivery module and delivery:read; a portal guest is refused.

Engagement Meetings tab: forum list with add forum, edit, stand down or reactivate, delete, preview upcoming dates, schedule a sitting, and the terms of reference editor

These routes keep the standing forums of an engagement, such as a steering committee or a weekly status call, with their chair, secretary, quorum rule, minutes approval settings, and terms of reference. A person can preview the dates a forum's cadence produces, marked where a sitting already exists, and create one sitting from the forum with everything except the date taken from it. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, view access for reads and preview, create access to add a forum or a sitting, update access to edit or save terms of reference, and delete access to remove a forum; a token needs the delivery read or delivery write scope. An engagement behind an information barrier or restricted to named people is refused before it is read, and a guest from the client portal cannot call these routes.

Engagement Meetings tab: meeting register with calendar toggle, open and delete actions; meeting workspace with details form, Start, Hold, record as held afterwards, Cancel, and bind or unbind a calendar meeting

These routes list, create, read, edit, and delete the meetings of one engagement, show them on a calendar window, and move a meeting through its life from scheduled to in progress, held, or cancelled. A meeting can be bound to a calendar meeting in the workspace so its provenance is recorded, and unbound again as a deliberate act. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, and view, create, update, or delete access on Client Delivery for the matching action, with the delivery read or delivery write scope on a token. Every lookup is scoped to the workspace and the engagement, so a meeting on another engagement or workspace returns 404, and an engagement behind an information barrier is refused before it is read.

Meeting workspace agenda: add item, move up or down, timebox, record outcome, mark decided, defer, remove, and the capture bar that raises a RAID item, a decision, or an action from an item; carried forward items from the previous sitting

These routes build and run the agenda of one engagement meeting and turn what was said into records: a capture creates a real RAID item or decision on the engagement register, or an action item on the engagement follow-ups, and links it back to the agenda item. The carried forward read lists what the previous sitting of the same forum left unfinished so the chair can pick it up. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, and view, update, create, or delete access on Client Delivery for the matching action, with the delivery read or delivery write scope on a token. The meeting workspace records outcomes through the agenda item edit; the separate outcome route is available to API callers and applies the same freeze rule.

Meeting workspace attendance list: add attendee, change role, mark attendance, send a delegate, remove; motion and voter fields to cast a vote

These routes keep the attendance list of one engagement meeting, including roles, voting rights, delegates standing in for members, and the recorded attendance status that the quorum rule reads. Votes are cast against a motion by a named attendee and the tally is stored with each vote. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, and view, update, or delete access on Client Delivery for the matching action, with the delivery read or delivery write scope on a token. A meeting on another engagement or workspace returns 404, and an engagement behind an information barrier is refused before it is read.

Meeting workspace minutes panel: minutes editor and Save, Import notes, Circulate, Approve, Reject, Dispute with a reason, Republish, version comparison toggle, minutes sheet and Print; Approve shortcut in the meeting register

These routes hold the formal minutes of an engagement meeting: save a draft, import the notes of a synced Granola meeting, circulate for approval with a due time, and approve, reject, or dispute. Approval freezes the record with a snapshot of the agenda, attendance, and votes and a hash, adds an entry to the engagement timeline, and republishing opens a new version without touching the approved one; the versions and diff reads show how the record changed. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, and view or update access on Client Delivery, with the delivery read or delivery write scope on a token. The meeting workspace saves through the PUT route; the POST draft route is kept for API callers and saves, then circulates when circulate is true.

Engagement Threads tab: open and breached filters, add thread form with kind, thread list, thread detail with first response, answer, close with reason, and reopen

These routes keep the question and request threads of one engagement, measure first response and resolution against the response target, and mark a thread as breached when the target passes. Reopening a thread increments a count, which shows questions that were closed before they were answered. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, and view, create, or update access on Client Delivery for the matching action, with the delivery read or delivery write scope on a token. An engagement behind an information barrier or restricted to named people is refused before it is read.

Engagement Stakeholders tab: add stakeholder form, power and interest grid grouped by strategy, overdue contact flags, and the interactions panel with channel, subject, and sentiment

These routes keep the stakeholder map of one engagement, with power, interest, sentiment, engagement strategy, and flags such as decision maker or signatory, and record each contact so the last and next contact dates are derived rather than typed. Logging an interaction with a sentiment also updates the stakeholder's current sentiment. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, and view or update access on Client Delivery, with the delivery read or delivery write scope on a token. An engagement behind an information barrier or restricted to named people is refused before it is read.

Engagement People tab, team panel: side, role, name, email, share email with client, and Add

These routes list and add the people on one engagement, firm side, client side, and third party, with their role, workstream, allocation, and whether they are key personnel. The identity used to detect duplicates is derived on the server rather than accepted from the caller. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, view access to list and create access to add, with the delivery read or delivery write scope on a token. An engagement on another workspace, deleted, or behind an information barrier returns a refusal before any row is read.

Engagement People tab, access grants panel: person, reason, expiry, workstream scope, Grant, and Revoke

These routes list, create, and revoke record-level access grants on an engagement that is restricted to named people. Revoking a grant records it on the engagement timeline in the same transaction and then closes the person's access on every transport: their guest membership, their current session, and their open realtime connection. Callers need admin access on the Client Delivery module as well as the workspace role Owner, Admin, or Member and the Client Delivery module on the workspace plan, with the delivery read or delivery write scope on a token. An engagement behind an information barrier is refused, and every grant and revocation is written to the audit log with its reason.

Engagement People tab, portal invites panel: contact picker, access role, Issue invite, copy link, and the invitation list

These routes issue a client portal invitation for one contact on one engagement and list the invitations already issued. Issuing returns the acceptance link and reports whether the email was sent, failed, could not be sent because the contact has no address, or could not be sent because email is not configured, and the link can be copied and handed over in every case. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, update access to issue and view access to list, with the delivery write or delivery read scope on a token. Both routes first check that the caller may see the engagement, so an engagement behind an information barrier, or restricted to named people without a grant for the caller, returns the same 404 as one that does not exist, and no seat is charged. Every issue is written to the audit log.

Engagement Ways of working tab, access provisions panel: system, access level, Add, and Revoke with evidence

These routes record the access each team member was given to client systems on one engagement and its revocation, so closing the engagement can check that nothing is still live. Revocation stores who revoked it, when, and the evidence, and writes an audit entry. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, view access to list, create access to add, and update access to revoke, with the delivery read or delivery write scope on a token. An engagement behind an information barrier or restricted to named people is refused before it is read.

Engagement Requests tab, request detail: share or withdraw toggle on each attached document

These routes decide whether an engagement document appears in the client portal by setting its audience to client or internal. Withdrawing a document removes it from the client's view but does not delete the file, and a client who already downloaded it still holds it. Callers need the workspace role Owner, Admin, or Member, the Client Delivery module on the workspace plan, and update access on Client Delivery, with the delivery write scope on a token. An engagement behind an information barrier or restricted to named people is refused before it is read.

Engagement Commercials tab: burn, effort and margin cards, the snapshot list, and the Take snapshot button; the Economics tab shows the same computed figures

The summary, burn, effort, and profitability reads compute the engagement's financial picture on demand from budgets, time, expenses, and billing milestones, so the figures are never stale. Capturing a snapshot freezes that picture for a day and source so a figure quoted to a client stays quotable later, and the capture is written to the audit log. Workspace owners, admins, and members may read and capture; guests are refused with 403, and a token needs the delivery:read scope to read and delivery:write to capture. The routes sit behind the Client Delivery entitlement.

Engagement Commercials tab, Rate cards panel: New rate card form, per-card Add rate form (grade, bill rate, cost rate), and the Show cost rates switch

These routes list the rate cards that apply to an engagement, including workspace-wide cards, create a card, and add or replace the bill and cost rate for a grade on a card. Workspace owners, admins, and members may read; only owners and admins may create a card or set a rate, because rates are a partner decision, and everyone else is refused with 403. Cost rates are hidden from members even when they ask for them. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Commercials tab, Budgets panel: New budget form, Edit form for planned cost and revenue, and Remove with confirmation

These routes list, create, edit, and remove the budgets an engagement is measured against, at engagement, phase, workstream, or deliverable level. Workspace owners, admins, and members may read; only owners and admins may create, edit, or remove a budget, and others are refused with 403. A token needs delivery:read to read and delivery:write to change, and the routes sit behind the Client Delivery entitlement.

Engagement Commercials tab, Expenses panel: status filter, New expense form, Edit form, and Submit, Approve, Reject with a reason, and Reimburse actions

These routes record expenses against an engagement, with the foreign exchange rate stamped at entry, and move each claim through submission, approval or rejection, and reimbursement. Workspace owners, admins, and members may list, create, edit, and submit; only owners and admins may approve, reject, or reimburse, and an approver can never approve their own claim. A token needs delivery:read or delivery:write, and the routes sit behind the Client Delivery entitlement.

Engagement Commercials tab, Billing panel: New milestone form and per-milestone actions to mark earned, invoiced with an invoice reference, or paid, and to dispute, hold, or write off with a reason

These routes keep the engagement's billing milestones and move each one through earned, invoiced, and paid, with dispute, hold, and write-off as recorded exceptions. The invoice reference is free text from the finance system; Atlas does not raise invoices. Every move is written to the audit log, and the first time a milestone is earned a milestone reached event is recorded. Owners, admins, and members may list, mark earned, dispute, and hold; only owners and admins may create a milestone, mark it invoiced or paid, or write it off. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Revenue tab: Record event form (type, date it occurred, basis), Attach to milestone control, and the onerous provision form (raised, amount, basis)

These routes record the events that make a fee recognisable, attach a recorded event to the billing milestone it supports, and raise or release the onerous contract provision on the engagement. Each write is recorded in the audit log, and releasing a provision clears its amount but still requires a stated basis. Owners, admins, and members may list, record, and attach events; only owners and admins may set the provision. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Obligations tab, Regulatory panel: regime picker with Seed, custom obligation form, due soon list, and Met, Waive with a reason, and status actions

These routes seed the obligations a set of regulatory regimes places on an engagement, record obligations the library does not carry, list them soonest deadline first, show what falls due in a window, and move each obligation's status. Every seed, record, and status change is written to the audit log. Workspace owners, admins, and members may use them; guests are refused with 403. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Commercials tab, Procurement panel: Start or Edit form (purchase order number, value, supplier registration, invoicing details) and the Draw down form with amount and note

These routes read and save the client's procurement record for an engagement, with the remaining purchase order headroom computed on each response, and draw the purchase order down. The first draw that crosses the warning threshold raises a high commercial risk on the engagement RAID register, once only. Workspace owners, admins, and members may use them; guests are refused with 403. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Commercials tab, Authority panel: Add band form (subject, threshold, approver, second approver) and the Preview chain form with subject and value

These routes list the delegation of authority bands that apply to an engagement, including workspace-wide bands, add a band, and derive the approval chain a given value would need so it can be seen before anything is raised. Workspace owners, admins, and members may list and preview; only owners and admins may add a band, and others are refused with 403. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement People tab, Team panel: Subcontractors list and the add form with name, company, and contract status

These routes list the subcontractors delivering on an engagement and add one, recording contract status, rates, insurance and NDA dates, and whether flow-down clauses are confirmed. Workspace owners, admins, and members may list; only owners and admins may add, and others are refused with 403. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Acceptance tab, Instruments panel: kind, status, and required controls with the Record button

These routes list the contracts and other legal instruments recorded on an engagement and create or update one per kind, with its status, dates, signatories, and governing law. Workspace owners, admins, and members may use them; guests are refused with 403, and an engagement hidden from the caller returns 404. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Working papers tab, Document handling panel: Add and Edit form, Verify redaction, Confirm insider entry, Release, and Recall with a reason

These routes keep the handling record for each deliverable version: classification, distribution limits, redaction and metadata scrubbing, and inside information flags, and they list each record with the blockers that would stop its release. Release and recall are written to the audit log, and a recalled document keeps its release date so the record shows it went out. Owners, admins, and members may list, save, verify, release, and recall; only owners and admins may confirm an insider list entry. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement Screening tab: suspicious activity section with the filed reports, shown only to the appointed reporting officer

This route returns the suspicious activity reports filed against checks on an engagement, with each check, kind, reference, and filing date. It answers every permitted reader in the same shape so the screen cannot tip anybody off: a reader who is not the appointed officer is told so and given an empty list. Workspace owners, admins, and members may call it with the delivery:read token scope; guests are refused with 403, and the route sits behind the Client Delivery entitlement.

Engagement Ways of working tab: escalation ladder with the add rung form (level, description, trigger, response time)

These routes list the engagement's escalation ladder, lowest level first, and add a rung naming who on the firm and client side it goes to and how quickly a response is due. Workspace owners, admins, and members may use them; guests are refused with 403, and an engagement hidden from the caller returns 404. The routes need the delivery:read or delivery:write token scope and sit behind the Client Delivery entitlement.

Engagement workspace Plan tab: add item form with kind picker, edit item dialog (title, dates, duration, percent complete), row move up and down, row delete, convert row to task, adopt tasks dialog, bulk select with shift by days, Gantt and card views, and the plan export button

These routes read and write the rows of an engagement plan: list, create, edit, delete and reorder rows, adopt existing project tasks into the plan, turn a plan row into a project task, shift many rows by a number of days, and read the plan as a Gantt view or as an export. Callers need the client-delivery module entitlement, a workspace role of OWNER, ADMIN or MEMBER, and module access of view, create, update or delete to match the action; a token needs the delivery:read scope to read and delivery:write to change anything. An engagement in another workspace, or one the caller is held off by an information barrier or by restricted access without a grant, answers 404, and converting a row to a task is refused when the call carries no user.

Engagement workspace Plan tab: dependencies panel (from, to, type, lag, hard link, check, create, delete), critical path filter, float ceiling filter, recompute button, and the replan panel with reschedule and level preview and apply

These routes manage the links between plan items and the schedule computed from them: list, add, edit, check and remove dependencies, read the critical path and each row's float, recompute the critical path, and propose or apply a reschedule or a resource levelling pass. Reads need module view access and the delivery:read scope, and changes need module update or delete access and the delivery:write scope, all behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. The critical path read never recomputes, a dependency that does not exist on the engagement answers 404, and an engagement the caller cannot see answers 404.

Engagement workspace Plan tab: baselines panel (open a baseline, set current with a reason, delete with confirmation), variance figures on the plan cards, and the milestone trend panel with its capture button

These routes freeze a copy of the plan as a baseline, choose which baseline the variance figures are measured from, compare the live plan against the current baseline or a named one, and record and read the milestone trend that shows how forecast dates moved over time. Reads need module view access and the delivery:read scope; capture, set current and trend capture need update access and delivery:write, and delete needs delete access, all behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. Capturing a baseline and changing the current one each write an audit record, and an engagement the caller cannot see answers 404.

Engagement overview lifecycle panel: phase gates list with pass and fail buttons, gate reason field and confirm; Workstreams tab: add workstream form (key and name) and the workstream register

These routes list and create the phases and workstreams that structure an engagement, and record a pass or fail decision on a phase gate. Reads need module view access and the delivery:read scope, creates need create access and decisions need update access with the delivery:write scope, all behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. A duplicate key is refused, a phase that does not belong to the engagement answers 404, and an engagement the caller cannot see answers 404.

Engagement workspace Scope tab: objectives list with the add objective form (statement, success measure, baseline and target values) and the scope register with in scope and out of scope statement forms

These routes list and add the objectives an engagement commits to and the statements of what is in and out of its scope. Reads need module view access and the delivery:read scope, and adding needs create access and the delivery:write scope, behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. An engagement in another workspace or one the caller is held off from answers 404.

Engagement workspace Ways of working tab: the ways of working form with one field per convention, the client visible switch, the agreed switch, and the save button

These routes read the single ways of working record for an engagement and create or replace it in one write. Reading needs module view access and the delivery:read scope, and writing needs update access and the delivery:write scope, behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. An engagement the caller cannot see answers 404.

Engagement workspace RAID tab: kind facets and search, add item form, bulk add rows, manage panel per item (owner, save, status buttons, score grid, review, escalate, resolve, void, remove), review mode with bulk review, item history panel, and load more

These routes run an engagement RAID register: list and read items, raise one or many, edit, move through working statuses, rescore, review, resolve, void, escalate and remove them, and read each item's event history. Reads need module view access and the delivery:read scope, raising needs create access, removal needs delete access and every other change needs update access with the delivery:write scope, behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. Each change writes an entry in the item's event log, and an item or engagement the caller cannot see answers 404.

Engagement workspace RAID tab: convert menu per item (to another kind, to a task, to a change request), share with client and withdraw with reason, and the import from project panel with the include closed switch

These routes move RAID items out of the register or across its boundary: convert an item to another kind while keeping the original as superseded, turn it into a project task or a change request, disclose it to the client and withdraw it, and seed the register from the linked project risk log. Kind conversion, sharing and withdrawal need module update access, while task, change request and import need create access, all with the delivery:write scope behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. Sharing is the only path by which a RAID item reaches the client audience, and both sharing and withdrawal write an audit record and an event on the item.

Engagement workspace RAID tab: summary tiles, heat map with cells by probability and impact, insights panel with ageing by kind, review mode window for due reviews, and the engagement export menu for the RAID log

These routes read the register as numbers and documents: the summary tiles, the probability by impact heat map, how long open items have been open, which items are past or near their review date, and the RAID log as a downloadable document. The four reads need module view access and the export needs module export access, all with the delivery:read scope behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. An unsupported format is refused with 400, and an engagement the caller cannot see answers 404.

Engagement workspace Responsibilities tab: matrix grid with letter cells and notes, coverage add subject, party picker, remove party, decision model switch, playbook apply, validate and violations only filter, publish, acknowledge, and export

These routes keep the engagement accountability matrix: list cells with their rule findings, assign, edit and remove cells one at a time or in bulk, list the subjects and parties the matrix can name, validate it, publish it as agreed, let each named person acknowledge their part, apply a playbook matrix, switch the decision model, and export the matrix as a document. Reads and acknowledgement need module view access and the delivery:read scope; every other change needs update access and the delivery:write scope, all behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. A cell or engagement the caller cannot see answers 404, and acknowledgement on behalf of another person is refused with 403.

Engagement workspace Responsibilities tab: responsibility cards with new area form (key and label), rename, move up and down, remove, assign and unassign, and the fill seats button with its result

These routes list the areas of responsibility on an engagement with who holds each, create, rename, reorder and remove areas, and fill the seats a playbook intended from the people now on the engagement. Listing needs module view access and the delivery:read scope; every change needs update access and the delivery:write scope, behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. Removal is a soft delete that writes an audit record, filling seats runs only when asked and reports what it did, and an engagement the caller cannot see answers 404.

Engagement workspace Structuring tab: issue tree with add question or hypothesis, reword, move, and conclude per node; analyses panel with add, edit, start, block with reason, and complete with finding and so what

These routes keep the problem structure of an engagement: list, add, reword, move and conclude questions and hypotheses, read them as a tree, and list, add, edit, start, block and complete the analyses that test them. Reads need module view access and the delivery:read scope, adding needs create access and other changes need update access with the delivery:write scope, behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. A hypothesis, analysis or engagement the caller cannot see answers 404.

Engagement workspace Structuring tab: interviews panel with add, record consent, and complete; sources panel with cite, reliability and credibility grading, retract, and corroborates or contradicts picks; storyline panel with add page, governing thought edit, move up and down, status, and mark evidenced

These routes hold the evidence behind an engagement: interviews with their consent and write-up, sources with their reliability grades and the sources that corroborate or contradict them, and the storyline pages the final answer is told through. Reads need module view access and the delivery:read scope, adding needs create access and other changes need update access with the delivery:write scope, behind the client-delivery module entitlement and a workspace role of OWNER, ADMIN or MEMBER. Grading and triangulating a source write an audit record, and an interview, source, section or engagement the caller cannot see answers 404.

Engagement workspace Requests tab: outstanding, overdue, blocking, with-client and with-us summary tiles, status filters, raise request form with category and line items, raise from a playbook template, request detail panel with edit form, add line and line received toggle, attach an engagement file, and delete a draft request

These routes raise information requests on one engagement, singly, in bulk, or by copying the information request section of a playbook, and they read the register, its chase board counts, the overdue list, each request with its lines, and the files linked to it. Workspace members with the OWNER, ADMIN, or MEMBER role can call them when the workspace holds the Client Delivery entitlement; reads need the delivery read scope and view access, writes need the delivery write scope and create, update, or delete access, and a portal guest is refused. An engagement behind an information barrier or restricted to named grants answers 404, as does a request, line, or attachment that is not on that engagement. Raising, deleting, bulk raising, and copying from a template each write an audit record.

Engagement workspace Requests tab detail panel: send to client, remind, escalate to a level, accept, reject with a reason, mark partially received, mark not applicable, and withdraw with a reason

These routes move one information request through its chase loop: send it to the client, remind, escalate up the engagement escalation path, and accept, reject, mark partial, mark not applicable, or withdraw what came back. Sending, reminding, and rejecting notify the client contact, escalating notifies the firm user on that level and adds an internal timeline entry, and each move except remind writes an audit record. The submit and review routes record a client submission and its review outcome on the firm side and have no control on the screen. Callers need the OWNER, ADMIN, or MEMBER role, the Client Delivery entitlement, the delivery write scope, and update access; a request or engagement the caller cannot see returns 404.

Engagement workspace Deliverables tab: deliverable register with load more and add deliverable form; deliverable detail page with advance stage buttons, acceptance blockers, acceptance criteria add, assess, and waive forms, capture version, request sign-off form with lapse period, and acceptance certificate download

These routes keep the deliverable register for one engagement: create a deliverable with its acceptance criteria, capture numbered versions, assess or waive each criterion, request a client sign-off with a deemed acceptance date, record the signature, and move the deliverable through its review stages to acceptance. Stage changes write an audit record and a signature is stored with a timeline entry the client can see. Recording the signature itself has no control on the internal screen and is reached through the API. Callers need the OWNER, ADMIN, or MEMBER role, the Client Delivery entitlement, and the delivery read or write scope, and a deliverable, criterion, or sign-off not on that engagement returns 404.

Deliverable detail page review panel: review rounds, record verdict form with outcome and comments, review checklist with YES, NO, and NA answers, and confirm review notes cleared

These routes run review rounds on one deliverable: open a round for a review gate, record the reviewer verdict, keep a question checklist for the round, answer it, and confirm that the review notes are cleared, which records who confirmed and when. Opening a round and setting its checklist questions are reached through the API; the screen reads the rounds, records verdicts, answers questions, and confirms clearance. Callers need the OWNER, ADMIN, or MEMBER role, the Client Delivery entitlement, and the delivery read or write scope with view or update access. An engagement the caller cannot see, a deliverable on another engagement, and a review on another deliverable all return 404.

Engagement workspace Changes tab: change register with status filter, add change form with urgency, cumulative drift panel; change detail page with edit form, assess impact form, add approver form, approval decision form, submit, start review, withdraw, defer, implement, share with client, unshare, and delete

These routes keep the change control register for one engagement: raise a change, assess its impact, submit it, send it to review, collect approver decisions, and withdraw, defer, or mark an approved change implemented. When the approval chain closes the decision applies its effect together with the change status, and the drift read recomputes cumulative cost, schedule, and scope change against the baseline and raises one steering review item when the workspace threshold is crossed. Sharing with the client and unsharing are the only paths that change the disclosure and each writes an audit record and an internal timeline entry. Callers need the OWNER, ADMIN, or MEMBER role, the Client Delivery entitlement, and the delivery read or write scope; a change or engagement the caller cannot see returns 404.

Engagement workspace Status tab: report list with load more and open report; compose page with period start and end, RAG lights, movement note, since last report panel, refresh figures, preview pane, sections, submit, approve, reject with reason, issue, supersede, share with client, unshare, recipients with add by email, and distribute with confirmation

These routes produce the periodic status report for one engagement: generate a draft prefilled from the previous report and current signals, edit its lights, narrative, and sections, refresh its figures, and move it through submit, approve or reject, and issue, or supersede it with a revised draft. Distribute records each unsent recipient as sent and returns the sent and skipped counts. Issuing adds a timeline entry, each status move and distribution writes an audit record, and sharing with the client is a separate, audited step. The plain create route and the delete route are reached through the API; the screen uses the draft generator. Callers need the OWNER, ADMIN, or MEMBER role, the Client Delivery entitlement, and the delivery read or write scope; a report or section not on that engagement returns 404.

Engagement workspace Acceptance tab: open acceptance file form, readiness blockers, check list with record result and waive forms, compliance terms, suspicious activity report for the reporting officer, start review, record the quality review, and decision form with conditions

These routes hold the client acceptance file for one engagement: opening it creates the screening checks its risk tier requires, results and waivers are recorded per check, and the decision accepts, accepts with conditions, or declines, with a timeline entry for every decision. Readiness returns every blocker at once, computed from what the reader may see. Members with OWNER, ADMIN, or MEMBER can read and record results, while only OWNER and ADMIN can decide, waive, or record the quality review, and only the appointed reporting officer can file a suspicious activity report; check rows mask that filing from everyone else. Editing the file and adding a check by hand are reached through the API. Every route needs the Client Delivery entitlement and the delivery scope, and an engagement or check the caller cannot see returns 404.

Engagement workspace Working papers tab: open file, add paper, prepare and review a paper with review method, lock blockers, clear review notes with confirmation, lock, verify integrity, legal hold and release, regulator access record, and destroy with typed confirmation

These routes keep the working paper file for one engagement: open it with its assembly standard and retention period, add, prepare, and review papers, confirm review notes are cleared, and lock the file with an integrity seal that the verify route recomputes and records. Legal holds, regulator access, post-lock additions, and destruction are each recorded with an audit entry, and a legal hold always blocks destruction. Updating file settings is reached through the API. Members with OWNER, ADMIN, or MEMBER can read the file and add, prepare, and review papers, while only OWNER and ADMIN can perform the custody actions; every route needs the Client Delivery entitlement and the delivery scope, and an engagement or paper the caller cannot see returns 404.

Engagement workspace header export menu: artifact picker, deliverable picker for single-record exports, internal or client edition, and download button that waits for a large export to finish

These routes list the export catalogue, render an artifact for one engagement in the requested format and edition, and run larger renders as background jobs that the requester polls and downloads once through a short-lived link. Requesting a job needs export access and writes an audit record. Listing jobs and requesting one directly are reached through the API; the screen polls the job and downloads it when the direct render is routed to a job. Callers need the OWNER, ADMIN, or MEMBER role, the Client Delivery entitlement, and the delivery read or write scope, and an engagement the caller cannot see is refused before any job is written, listed, read, or downloaded. The job list returns the requester's 25 most recent jobs on this engagement only.

Engagement workspace Closure tab: independence declaration list with gap flags, rotation register with the add-person form (person, rule, role, first year, years served), non-audit service register form (description, rationale, pre-approval reference, fee, currency), and the fee-cap position panel with audit fee and public interest entity inputs

These routes keep the independence record for an engagement: independence declarations, the partner rotation register for a client with its rule catalogue, and the register of non-audit services that feeds the fee-cap position. Only workspace owners, admins, and members may call them, checked both by the route guard and again in the service, so a client portal guest is refused. The Closure tab reads declarations and the rotation register and records rotation entries and non-audit services; recording a new declaration is available through the API only. A breach flagged without detail, an unknown rotation rule, and a blank non-audit description are refused. Every engagement-keyed route first checks that the caller may see the engagement, and a rotation entry naming a client account outside the workspace is refused.

Engagement workspace Closure tab: quality reviewer appointment with trigger reason, unresolved matters count and save, complete review button, difference of opinion raise and resolve forms, and the report dating verdict with every refusal listed

These routes run the engagement quality review: appoint a reviewer, record how many matters remain unresolved, complete the review, raise and resolve differences of opinion, and read every reason the report cannot be dated yet in one call. Only workspace owners, admins, and members may call them; a client portal guest is refused at the route and again in the service. The service refuses an appointment where the engagement partner appoints or reviews their own engagement, refuses completion while matters are unresolved or once the report date has passed, and returns 404 for a review or difference from another engagement or workspace. Resolved differences stay in the register as the record that they happened.

Engagement workspace Follow-ups tab: add follow-up form (kind, title, due date, lead time), the list of follow-ups with acknowledge, complete, pause, snooze, and cancel actions, the due and mine views, and the automatic rule toggles

These routes create, list, edit, and act on follow-ups that chase an action or a person on an engagement, including what is due soon and what the caller personally owes. Only workspace owners, admins, and members may call them, with the client-delivery view, create, update, or delete permission for each action, and a token needs delivery:read or delivery:write. DELETE cancels the follow-up rather than removing it, so the record that a chase was called off remains. The runs route is read only, because delivery records are written by the background sender. The service refuses an engagement the caller cannot see behind an information barrier, a follow-up from another engagement, a snooze into the past, and any change to a closed follow-up. The background sender asks whether each recipient may see the engagement before it emails them, notifies them in the app, or tells them about an escalation; a recipient who may not is skipped, and the run records the skip.

Engagement workspace Client voice tab: request feedback form (kind, respondent, anonymous), record response form (score, verbatim), consent to quote and reference toggles, follow-up complete action, quotable verbatims list, and the complaint register with raise, acknowledge, resolve, close, and escalate actions

These routes record what the client says: feedback requests and responses with consent to quote, the list of poor responses still owed a follow-up call, and the complaint register from raising to closing. Only workspace owners, admins, and members may call them, with the client-delivery view, create, or update permission, and a token needs delivery:read or delivery:write; there is no client portal counterpart. The quotable list leaves out the respondent label for anonymous respondents. The service checks that the engagement is visible to the caller, enforces the acknowledge, resolve, close order, and refuses changes to a closed complaint.

Engagement workspace People tab: raise staffing request form (role, grade, allocation, key personnel, client approval), propose, confirm, record client approval, and decline actions, the weekly capacity view, and the transition panel with knowledge transfer completion and open defects

These routes raise and progress staffing requests for an engagement, report planned capacity for a week after ramp-up, and keep the single transition plan that hands the work to the client team. Only workspace owners, admins, and members may call them, with the client-delivery view, create, or update permission, and a token needs delivery:read or delivery:write. PUT on the transition plan edits the one plan for the engagement rather than adding another. The service refuses confirmation without a proposed person or a required client approval, refuses a proposal the export control check rules out, and refuses invalid hypercare or warranty windows. Every route first checks that the caller may see the engagement.

Engagement workspace Expert calls tab: request form (network, expert reference, topic, justification, compliance flags), approve with chaperone, record as held, flag an incident with a reason, and the compliance review of open incidents

These routes keep the register of expert network calls for an engagement: request a call, edit it, have somebody else approve it, record it as held, flag an incident where material non-public information came up, and record the compliance review of that incident. Callers need the client-delivery view, create, or update permission, and the service allows only workspace owners, admins, and members, so a client portal guest is refused; a token needs delivery:read or delivery:write. The service refuses self-approval, approval after the call, holding an unapproved call, a flagged call without a chaperone, direct payment, and a fifth held call with the same expert in a year.

Engagement workspace Barriers tab: raise barrier form (type, code name, reason), wall crossing form with purpose, close crossing action, insider list with add form (name, function and reason) and notified and acknowledged steps

These routes raise information barriers on an engagement, record who is let through a barrier and on whose authority, close crossings, keep the insider list with its separate notification and acknowledgement steps, and return the name a caller is entitled to see. Only workspace owners, admins, and members may call them, with the client-delivery view, create, or update permission, and a token needs delivery:read or delivery:write; a client portal guest is refused. A member excluded by an active barrier on the engagement, without an open crossing, cannot read or administer that barrier and receives the same 404 as for an engagement that does not exist. Crossings are append-only, cannot be recorded by the person crossing, and must be approved by a workspace owner or administrator other than that person. The service refuses side conflicts, crossings on an inactive barrier, unnamed insiders, and out-of-order acknowledgements.

Engagement workspace Assistant tab: propose a status report draft, minutes from a meeting, RAID items from meetings, a deliverable pre-check, or a health explanation; pick the parts to keep and accept or decline the proposal, with provenance shown beside it

These routes ask the configured model provider for drafts on an engagement and keep each proposal until a person decides it: status report prose, meeting minutes, proposed RAID items, a deliverable pre-check against its acceptance criteria, and an explanation of the health score. Only workspace owners, admins, and members may call them; producing a draft needs the client-delivery create permission because it spends the AI budget, and accepting or rejecting needs update, with a token carrying delivery:read or delivery:write. Accept is the only route that lets model output reach a register, and it writes only the keys named. The service refuses drafts without a configured provider or budget, and refuses a second decision on a draft that is already decided.

Engagement workspace Assets tab: harvest form (kind, title, description, client consent required), sanitise, record consent, and reuse actions on each asset

These routes harvest reusable assets such as templates, models, and case studies from an engagement, mark them sanitised, record client consent, and record a reuse. Only workspace owners, admins, and members may call them, with the client-delivery view, create, or update permission, and a token needs delivery:read or delivery:write. The service refuses reuse of an asset that has not been sanitised or that needs client consent which is not on record, and refuses an asset from another engagement. Every route first checks that the caller may see the engagement.

Engagement workspace Benefits tab: record benefit form (type, name, measure, unit, baseline, target, attribution, double-count note) and the take reading form (date, value, source)