Security and data handling

A plain-language guide to where Org Loom processes and stores data, how Salesforce access works, and when another service receives data.

Last reviewed August 3, 2026

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, and org switching. 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.
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 fields and records are encrypted before they are stored in a private contribution record. The canvas owner merges accepted responses into the saved canvas.
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. Sign out and close sensitive tabs when using a shared device. Temporary collaboration state is cleared by a server restart. After everyone leaves a shared canvas, an unsaved handoff copy may remain in server memory for up to ten minutes.

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 held in your server-side session, not browser storage, and is cleared when you sign out or disconnect the org.
Refresh tokens are not persisted. A refresh token is never written to Org Loom’s database or disk. It is held only in process memory and is discarded when you sign out, disconnect the org, or the server 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 acceptance.

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.

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 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 during an authorized owner merge.

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 automatically included. Any record data you type into the prompt is sent. 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. The client proposes changes for human review; it 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: Timestamps, actors, actions, record IDs or counts when needed, and minimized operational status. Activity History does not contain Salesforce record field values and is not represented as a compliance-grade audit log.
Billing: Stripe customer and subscription references. Stripe, not Org Loom, holds card numbers and payment credentials.
Analytics and error reporting: Product events use a hashed account identifier. Session replay and automatic DOM capture are disabled on signed-in pages. Sanitized error reports exclude request bodies, query strings, cookies, authorization headers, and Salesforce record values.

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.