Org admins for teams on Coda’s Enterprise plan can already control which Packs are accessible to users within their workspaces. And with custom Pack configurations, org admins (as well as org Pack admins) have the additional ability to control:

• Who can add connections for a Pack in the organization’s docs

• What functionality of that Pack can be used and how users can use the Pack

• How docs containing that Pack can be shared within their organization

For example, you might want to allow org members to only be able to view data from the Slack Pack without being able to take actions in Slack. Or maybe you want Group A to access all projects from the Jira Pack, and block Group B from accessing ProjectX.

Furthermore, you can also optionally create configs to enforce DLP-like controls over how docs containing sensitive Pack data are shared, and ensure that only the designated users or groups have the privilege to access documents containing Pack data defined in the config. For example, Admins can allow only GroupB to access the revenue reports from SFDC and also ensure that the doc with this SFDC data cannot be shared with anyone outside of the members in GroupB.

If you’re an org admin or org Pack admin, you can create these Pack configs using JSON to only authorize access to specific parts of a Pack for specific users (or user groups). Read on to learn all about Pack configurations!
 

Within this article, you’ll find...

• Getting started

• Create custom configurations

• User experience with Pack configurations

• FAQs

Getting started

All Pack approvals and configurations can be managed in the Pack approvals section of your admin settings. To open your admin settings, just click on your account name in the lower-left corner of a Coda page, then select Admin settings from the menu.

If you want to require admin approval for all Packs, you can toggle on the Require admin approval and policies setting, which will require org members to request approval anytime they want to add a new Pack to a doc. Org admins will then have to approve or deny each Pack request. Learn more about Pack requests and approvals here.

But if you don’t want the overhead of reviewing and approving every single Pack request, you can pre-configure how certain Packs can be used by specific members (or groups) of your organization. The section below will dive into how to create the configurations. But first - a bit of context:

Packs can be in one of the following three states within your organization:

• Approved Packs: They can be used by any user on docs within workspaces in your organization. This includes users outside of your org.

• Denied Packs: They can not be used by anyone. Your org users can not install or connect an account to this Pack in any doc.

• Configured Packs: They have configurations created by the org admin that dictates who has access to these Packs and how they can be used. Users outside your org will not be able to use these Packs with their accounts on docs within workspaces in your organization. Similarly, org users will not be able to use these Packs in workspaces that are outside of your organization. Learn about these custom configurations in the following section.

The Packs approvals section of your organization will show the following tabs:

• Packs you have configured or denied/allowed: If Pack approvals are disabled, this tab will show a list of Packs that have been configured for members in your organization to use, and Packs that are explicitly denied with a configuration. If Pack approvals are enabled, this tab will contain a list of Packs that have been approved for all users or approved with a configuration.

• Packs used in your organization: This tab shows all Packs that have been installed in the docs in your organization, or Packs with an account connected by a user in your org.

• All Packs: This tab will show all Packs that you and users in your organization have access to. You can pre-configure or approve/deny access to any of these packs if needed.

Create custom configurations

To get started with creating Pack configurations, follow these steps:

1. Go to coda.io/docs

2. Click on your name in the lower-left corner, then select Admin settings from the menu

3. Navigate to - or search for - the Org Pack approvals tab

4. Scroll to see the list of Packs, and click the Packs used in your organization tab

5. Find the Pack you’d like to configure. Expand to see details.

6. To create a new configuration for the Pack, click + Add new configuration

   1. Note: When you configure a Pack, the default configuration is set to Allow all access, which means any member within your organization can install the Pack and access all functionalities.

7. To modify an existing configuration, click on the vertical three dots to the left of the existing configuration. Then select Configuration policy settings.

From here, there are two main ways to utilize Pack configurations:

1. Limit which users have access to a Pack (Restrict Pack users)

2. Limit how those members can use the Pack (Restrict Pack functionality)

Check out the corresponding sections below for details on each.
 
 

Restrict Pack users

To change who can access a specific Pack, click on the three-dot menu to the left of the configuration and select Configuration policy settings. Then, under the Permissions section, select the Named users and groups only option.

Then you can add specific users and groups that are allowed to use this Pack below. If you use SCIM groups, you should be able to see and select your SCIM groups in auto-suggest as you type. Be sure to click Save configuration to save the changes.

To delete a user or group from having access to Pack, you can click on the delete button (small x) next to the user or group name.

 

Restrict Pack to specific docs

You can also use Pack configurations to limit the Pack to only being installed in specific docs. This requires more effort to manage, but can be useful for particularly sensitive Packs.

The list of allowed docs is specified in the Pack configuration policy JSON, as an array of either doc IDs or URLs.

{
  "doc": {
    "sharing": {
      "allowedDocs": [
        "https://coda.io/d/_dabcdefhijk",
        "https://coda.io/d/_dlmnopqrstu"
      ]
    }
  }
}

Restrict Pack functionality

If you want to control what aspects of the Pack is made available to specific users and groups, you can do so by editing the Pack configuration. The configuration uses a JSON schema and is flexible in supporting any policy you might want to set.
 

Restricting Pack components

There are two flavors to choose from when restricting Pack functionality:

• Broad-based restrictions: You can independently choose to allow Pack components that fetch data from the third-party system (called fetches ) and Pack components that update data in the third-party’s system (called actions)

• Granular restrictions: You can choose to enable individual formulas in the Pack (via the formulas configuration) and individual Packs tables (via the syncTables configuration).

If you choose to restrict Pack components via either of these directives, any Pack component that is not explicitly enabled will be disallowed.

If you want to control what aspects of the Pack is made available to specific users and groups, you can do so by editing the Pack configuration. The configuration uses a JSON schema and is flexible in supporting any policy you might want to set.

You can see what building blocks and OAuth scopes are used by a Pack by clicking on the open button next to the heading. You will be taken to the Packs page which has all the details about the Pack in the About and Security tabs to help you decide if you want to restrict access to any part of the Pack.

To get started easily, you can click on the Quick start menu to see the syntax for a few examples of policies that you may want to set for the Pack. You can select one of these examples and click on the Use button to apply the syntax.

Note that the Quick Starts are meant to just provide the initial outline. You must then edit the initial outline of configuration policy with the necessary details.

Here’s a little bit about the different kinds of Quick Start policies you can configure for a Pack:

• Allow all usage: This is the default option that allows unrestricted access to all building blocks and functionalities of a Pack.

• Only allow buttons with private connections: Use this to only allow users to use buttons connected to accounts for taking private actions.  Synced accounts will be disabled for all actions, and other functionality of the Pack such as sync tables will also be disabled.

• Only allow a few Packs tables: Use this to only allow users to specific authorized sync tables. All other sync tables, and other functionality of the pack such as buttons will be disabled.

• Restrict sharing to users who can access this Pack config: Use this to restrict sharing of docs with Pack data to only the set of users that have access to the Pack. Sharing of the doc with anyone else will be disabled.

  • Note: This is a restrictive action and we only recommend using this policy on Packs that have sensitive data that shouldn’t be visible to users outside authorized SCIM groups.

• Allow explicitly declared OAuth scopes: Use this if you want to allow specific OAuth scopes that the Pack has permission to.

For a detailed set of examples, please see our Configuration cookbook.
 

Restricting Pack component inputs

If you implement granular Pack component restrictions (via above), you can choose to further restrict inputs to those components in order to solve a particular use case. This is accomplished via the following

• For Pack tables and formulas, inputs to these components can be restricted by editing the parameters component of the config.

• For dynamic Pack tables, the dynamicUrl input can be restricted by editing the dynamicUrl component of the Pack table config.

If a configuration has a restriction on an input (parameters or dynamicUrl), then that parameter will be required and must pass validation in order for the component to work.

Please see Configuration cookbook for some examples of how this can be used.
 

Best practices

Any changes you make to Pack configurations will have an immediate impact on users and docs within your organization that rely on that Pack configuration.

Typically, it is desirable to test out a new Pack configuration by:

• Creating a new configuration (not disrupting any existing configurations)

• Sharing that new configuration with a trusted set of testers and using that Pack configuration in a doc, iterating on it as required.

• After the policy has been deemed suitable to the use case, there are two different ways of rolling out the change, depending upon if this is a newly approved Pack or one already in use.

  • For a newly approved pack, share the newly created configuration with the users who require it

  • If there is an existing configuration already in live docs, modify the existing configuration. Then, delete the configuration used to test the policy.
    
     

Additional documentation

There are several mechanisms for getting help with writing Pack configurations:

• Contextual editor help: In the Pack configuration editor, as you edit the JSON config there will be tooltips over the various options, autocomplete for options, and highlights for issues in the schema.

• Schema documentation: On every Pack listing page (linked from the Coda gallery or the Pack configuration editor), the Administer tab contains a full list of JSON options for the particular pack (including the various formulas, Pack tables, and parameters).

• Configuration cookbook: Detailed examples of some common use cases for Pack configurations.
   

User experience with Pack configurations

This section explains what members of your org will experience when encountering various aspects of Pack configurations.

When installing a Pack

When a Pack is installed, the configuration associated with that Pack (and all policies contained within) is bound to that doc until the Pack is uninstalled from the doc.

• If the user does not have access to any Pack configurations: If none of the existing configurations for that Pack give access to this particular user, the user will be unable to install a Pack and will be given the option to request access to a Pack.

• If the user has access to multiple configurations: In some instances, it may be desirable to have multiple configurations for a single Pack. For example, you could have a limited Pack configuration applicable to your entire organization, and then a more open configuration for a trusted set of users. In such a case, the installing user will get a prompt similar to the one below, asking them which configuration they want to bind to the Pack.

Disabled Pack functionality

When an org admin restricts Pack functionality, this is exposed to the user via a number of mechanisms.

• Disabled user experience: Coda will disable parts of the Packs experience that are incompatible with the installed Pack configuration of the doc. Members will see a message in their doc that explains the limitation.

• Runtime errors: When an action occurs that violates the policy of a Pack configuration, Coda will return an error telling the user that the action they tried to perform violates the policies of the IT administrator.

• Uninstalling a Pack: When an action occurs that causes the doc and Pack to become incompatible with the configuration that the Pack was installed with, the Pack will be uninstalled. For more details on when this happens, see Policy enforcement amid changes.

FAQs

Related resources

• Enable Pack approvals and manage requests

• Overview: Enterprise security features