Inside this article

Coda has built the Packs platform with security features from the ground up and provides transparency on how each Pack uses your data so you can decide if you’re comfortable installing it.

Designed with security from the ground up

Restricted network requests: We ensure Packs only share data with the website they say they do. Some of our most popular Packs are integrations — connections to external data sources. Pack makers must declare which domains their Pack connects to, which we publish to users of the Pack in each Pack’s Security tab, found on the Pack listing page. Coda enforces that Packs can only ever connect to these declared domains.

Locked-down authentication: We never let developers touch users’ login details. For Packs that require user authorization credentials, Coda handles credentials on behalf of the Pack, stores them encrypted at rest, and applies them to outgoing requests such that neither Pack code, Pack makers, nor other users of a doc ever have access to them.

Just what you share, and no more: When a Pack is executed, it only receives the data that the user explicitly provided — e.g. formula parameters — and no other content from your doc.

Rigorous evaluation: Packs run in a dedicated, secure infrastructure. We execute Packs in a secure sandbox environment that isolates Pack executions from Coda’s broader infrastructure, and data, and from other executions of Packs. The infrastructure receives an annual professional penetration test and receives constant evaluation via Coda’s bug bounty program.

Covered by everything that already makes Coda secure: SOC 2 Compliant, data encryption, data access controls, and more all come standard with Coda. Learn more.

How do I understand the security of an individual Pack?

In the gallery listing for each Pack, you’ll see a Security tab. Here, you may see some or all of these sections, based on what features the Pack uses:

  • Makers: The users or organizations who build this Pack

  • Domains accessed: Lists which domain(s) the Pack can make HTTP requests to. We enforce that the Pack cannot send or receive data to any other domain.

  • Authorization type: Identifies how the user is authenticated with an external service (e.g. Gmail), via the external API used by the Pack.

  • Authorization and Token URL: If the Pack uses the OAuth2 standard, lists the URLs the Pack uses to obtain your credentials for the external API used by the Pack.

  • Scopes used: If the Pack uses the OAuth2 standard, lists the type of data that the Pack can read/write on your behalf via the external API.

  • Resources: Pack maker-provided terms of service and privacy policies.

  • Help: Contact the Pack maker with questions or issues at their support email address.

  • Report: Report violations of our policies

Note: Pack code is proprietary to the Pack makers and thus Coda has not evaluated individual Pack code.

How does data flow through Packs?

Packs integrate data into Coda docs in two ways:

  1. Pulling data in, such as a dashboard embedded into a project management hub.

    1. Think of this as ‘read-access.’ You can see but you can’t touch. Ideal for status updates, presentations, and centralized working hubs. Some common examples are embedded Figma files or YouTube videos.

  2. Pushing data out, such as a button that pushes updates to a Jira board.

    1. Think of this as ‘write-access.’ You can act on the data — update status, send a message to Slack, email notes via Gmail, or create a new GCal event.

Note that these integrations are on a per-doc basis, not across all docs connected to a user or an entire workspace. When you enable a Pack for one doc, this does not enable that Pack for all docs in your workspace or all docs that you’ve created. This means each doc can have a different Pack setup depending on your specific needs.

When you sign in to an account to install a pack you can set up permissions for who can access data and who can take actions with the account from the Coda doc.

Pulling in third-party app data into your Coda doc

Packs have granular sharing settings to protect your privacy. When connecting a Pack to your Coda doc, you have two sharing options:

  1. You and anyone this doc is shared with ー Setting this access for an account will set up a shared account. Users will be able to create sync tables and view data, use formulas and column formats.

    You might choose this option for personal docs or if the information should be viewed by everyone in the doc. For example, a shared team Google Calendar or a Mode Dashboard that tracks your team’s OKRs.

  2. Nobody ー this limits the data from being pulled into the doc, so it can only be actioned on by you. Setting this access for an account will set up a private account. No Sync tables can set up for this account and Coda will not pull in data from the account to use formulas or column formats.

    If you select Nobody, only you can take actions on this account. For example, with the Gmail pack, only you can send an email or create a draft. You might choose this to control permissions on Gmail pack when you don’t want anyone to pull data from your Gmail, but you do want to use the button to send emails from your account.

Pushing Coda doc data to a third-party app

Packs can pull data in and can also push data out. You have three options to choose from to ensure your data is always secure:

  1. Only you ー you are the only one who can push out any actions or data from the Coda doc to the third-party app, other users will have to sign in with their own accounts to take actions with the pack. While users can access the pack tables, they will not be able to take actions with buttons.

    For example, you may have the Slack Pack enabled for your doc and you’ll be the only one who can push messages from your doc to Slack. Each user can set up their own Slack Pack so they can all push out messages from their own account.

  2. Anyone this doc is shared with ー any user who can access the doc can push out data. Setting this access for an account will set up a shared account and any user may take actions on behalf of this account.

    If we continue the Slack example, this means that everyone in the doc can push out messages from your doc to Slack from your Slack account ー without having to set up their own accounts.

  3. Nobody ー this setting restricts any action being taken and only allows users to view data.

    You might want to choose this option if you intend your doc to be strictly informational and connect data, rather than pushing data out.

After you have signed in to an account you can make changes to the permissions in the explore panel.

Managing Packs Approvals for Enterprise Admins

Admins for teams on Coda’s Enterprise plan can control which Packs are accessible within their workspaces. You can find more information here.

Other Packs Resources

Did this answer your question?