Security and data handling

Where Org Loom processes and stores data, how Salesforce access works, and when another service receives data.

Overview

Salesforce record field values are not stored in Org Loom’s application database.
Saved canvases are encrypted and stored in your Salesforce org.
Submitted teammate responses are encrypted and stored in your Salesforce org. Valid responses synchronize into live collaboration or merge when the canvas owner next loads or saves the canvas.
Org Loom acts through the connected Salesforce user and is limited by that user’s Salesforce permissions.
The canvas core is source-available in the public Org Loom Canvas repository.
Salesforce access tokens stay in server-side session records. Refresh tokens stay only in process memory and are never written to the database or disk.
AI features receive data only when you choose to use them, as described below.

Where your data lives

Data	Where it is kept	What to know
Active canvas and unsaved changes	Your browser tab; temporary server memory while shared	Held in browser memory and tab-scoped session storage for refresh recovery, temporary drafts, imports, and moving a canvas between orgs. This storage can contain Salesforce record values. Values and clear instructions entered for Salesforce encrypted fields remain only in active-tab memory and are excluded from session storage. While people actively collaborate on a saved canvas, Org Loom also keeps a bounded live copy in server memory for synchronization. It is not written to the application database. Durable browser local storage contains preferences and the synthetic public playground dataset, not Salesforce record content.
Saved canvas	Your Salesforce org	Stored as an encrypted Salesforce file associated with a private Org Loom canvas record. Org Loom keeps the latest three encrypted saved bodies for recovery; if cleanup is interrupted, older encrypted copies may remain temporarily.
Submitted teammate responses	Your Salesforce org	Requested canvas updates are encrypted before they are stored in a private contribution record. Valid submissions synchronize automatically during live collaboration or merge when the canvas owner next loads or saves the canvas. The contribution record remains in Salesforce with its processing status.
Upload Recall information	Your Salesforce org; wrapped key in Org Loom’s application database	Before an upload, Org Loom encrypts the information needed to identify and reverse supported changes, including affected Salesforce record IDs and changed fields’ prior values. The encrypted ledger is stored as a Salesforce file. Values for Salesforce encrypted fields are excluded. Its wrapped data-encryption key is stored in the `batch_keys` application-database table and cannot decrypt the ledger without the key-encryption key in your Salesforce org.
Salesforce record field values	Processed temporarily	Read through your Salesforce connection and returned to Salesforce when you upload. They are not stored in Org Loom’s application database.
Account and workspace information	Org Loom’s application database	Includes identity, membership, role, plan, connection metadata, and minimized activity information needed to operate the service.

Browser session storage is shorter lived than local storage, but a browser may restore an open tab after a restart. Recovery snapshots and temporary draft values expire two hours after their last save; org-switch handoffs expire after ten minutes. Expired copies are removed when checked, with periodic cleanup while the page is running. Browser suspension can delay cleanup, but expired copies are not restored. Signing out, or detecting an expired Org Loom account session, clears record recovery storage. Other open tabs receive a logout notification; suspended tabs check for missed notifications when resumed. Recovery storage is not application-encrypted. Sign out and close sensitive tabs when using a shared device. Temporary collaboration state is cleared by a server restart. After the last browser disconnects from a shared canvas, an unsaved working copy may remain in server memory for up to ten minutes to support reconnection.

How the Salesforce connection works

You sign in on Salesforce. Org Loom never receives or stores your Salesforce password.
Access tokens stay server-side. The short-lived Salesforce access token is stored with your active server-side session in the application database’s session table, not in the browser cookie or browser storage. It is removed when you sign out, disconnect or remove the Salesforce connection, delete your account, or the session expires or is invalidated.
Refresh tokens are not persisted. A refresh token is never written to Org Loom’s database or disk. It is held only in the running web process’s memory and is discarded when you sign out, disconnect or remove the Salesforce connection, delete your account, or the process restarts.
Reauthentication may be required. Because Org Loom does not persist refresh tokens, a server restart or expired Salesforce session can require you to connect again.

Salesforce permissions remain in control

Org Loom calls Salesforce as the person who connected the org. Salesforce object access, field-level security, record sharing, and other platform controls remain the authorization boundary. Org Loom cannot grant a user Salesforce access they do not already have.

Each collaborator uses their own Org Loom account and Salesforce user. Before shared-canvas content is sent to someone, Org Loom filters it using that person’s Salesforce access. Content they cannot access is hidden, and contributor responses are checked again against the current request and the contributor’s object and field permissions before synchronization or merge.

The managed package permission set grants access to the package’s canvas, contribution, activity, and encryption services. It does not expand access to your business objects or fields. Workspace and canvas roles can further limit what a member may do in Org Loom.

Team workspace administrators can optionally restrict Salesforce connections to a workspace-wide list of approved orgs. Administrators enter each org’s Current My Domain base URL and can apply the list to production orgs only or to every Salesforce org type. Org Loom checks the org during Salesforce authorization and checks saved connections again when they are used.

How saved canvases are encrypted

Each saved canvas has its own data-encryption key. The encrypted canvas body is stored in Salesforce. The key that protects each data-encryption key is stored in your Salesforce org as a protected managed-package setting and can be used only through the package’s Apex service. Org Loom stores the wrapped, unusable-on-its-own data-encryption key in the canvas_keys table in its application database so an authorized session can open the canvas.

Canvas bodies use AES-256-GCM encryption, and network traffic uses TLS. Plaintext exists transiently while an authorized request is being processed and is not written to Org Loom’s application database.

Submitted teammate responses use the same canvas encryption boundary. Their field values are encrypted before storage in Salesforce and are decrypted only when an authorized live session synchronizes them or the canvas owner loads or saves the canvas.

AI features and AI client access

Generate with AI

When you choose Generate with AI, Org Loom sends your prompt and the selected Salesforce object and field schema to Anthropic. Existing canvas record values are not sent to Anthropic unless the user specifically includes them in the prompt. The generated result returns to the canvas as drafts and is not written to Salesforce until you choose to upload it.

MCP and your own AI client

MCP uses the AI client and model provider you configure. When you ask that client to use an Org Loom tool, it can receive the canvas information returned by that tool. Changes are presented for review unless the user explicitly enables automatic application for that canvas. Automatic application can change the working canvas but cannot upload records to Salesforce. Pending proposals and clarifications are held in Org Loom process memory for no more than 24 hours and are cleared on a server restart. Review your AI provider’s data handling terms before connecting it.

Data needed to operate the service

Account and workspace data: Email and display name, workspace name, plan, members, roles, invitations, and feature settings.
Salesforce connection metadata: Salesforce org ID, instance URL, and username. This lets Org Loom identify and display connected orgs without storing your Salesforce password.
Trial eligibility: One-way hashes derived from the Salesforce organization and user IDs, plus the claim time, prevent repeated trial redemption. The trial ledger stores neither the raw Salesforce IDs nor an Org Loom account or workspace ID.
Activity History: Org Loom stores fixed operational metadata such as timestamps, actors, actions, status, request identifiers, and the connected Salesforce org and user identifiers. Its application database does not retain Salesforce business-record IDs, object or field API names, record field values, or free-form Activity History payloads. Selected aggregate summaries of Salesforce operations are stored in Audit_Event__c records in your Salesforce org.
Billing: Stripe customer and subscription references. Stripe, not Org Loom, holds card numbers and payment credentials.
Analytics and error reporting: We use a self-hosted instance of GlitchTip, an error-monitoring tool, to diagnose unhandled errors and selected caught errors or operational failures. Product events use a hashed account identifier. Session replay and automatic DOM capture are disabled on signed-in pages. Reports retain stack locations and a pseudonymous account hash, but exclude request bodies, request headers, query strings, free-form messages, and Salesforce record values. GlitchTip performance tracing, SDK log collection, and session replay are disabled. Error reports are retained for 90 days. See what error reports contain in our Privacy Policy.

Source transparency

Org Loom publishes its canvas core in the Org Loom Canvas repository. The public deployment version manifest identifies the application commit reported by the running service and links to its corresponding canvas-source tag.

The manifest supports release traceability but is not remote cryptographic attestation. The repository contains the canvas core, not Org Loom’s private account, billing, or administration code.

Deletion and retention

Deleting an Org Loom account or workspace removes the associated service data according to the controls and retention periods in the Privacy Policy. One-way trial eligibility hashes remain so deletion cannot restart a one-time trial.
Saved canvases, submitted contribution records, and activity records stored in Salesforce remain under your organization’s control. Delete those records in Salesforce if you also want them removed from the org.
Stripe may retain billing records as required for payment, tax, and legal obligations.