Note: This article discusses a feature that’s only available to org admins on our Enterprise tier.

Packs are powerful building blocks that connect your Coda doc to the apps you use everyday—the tools you and your team communicate, code, and design in. Because Packs connect to third-party apps and tools, most require additional authentication (read more about the security of Packs here). For added security, org admins for teams on Coda’s Enterprise plan can control which Packs are accessible within their workspaces.

All team members can still make requests to use admin-disabled Packs via their docs, and admins can review, approve, or reject these requests from their admin settings center. If multiple team members request to use the same Pack, admins can view and manage all requests in aggregate for each Pack. Read on to learn more!

In addition to managing and approving Packs that can be used by members of your organization, org admins can get even more granular with their Pack usage controls. They can choose to allow only specific users or groups to access a Pack, and also allow only specific functionalities of the Pack. To learn more about advanced access control for Packs, see this article.

Enable Pack controls

To get started, you first need to enable Pack controls for your org. This means your org will go from the default state of allowing all Packs to be used by all org members, to a more restrictive and secure state where Packs require admin approval to be used.

If you’re an org admin on an Enterprise plan, you can follow these steps:

Go to coda.io/docs
In the left panel, select Admin settings
Search for - or scroll to - the Packs approvals tab (within the Packs section)
Toggle on the Require admin approval and policies setting

Once this setting is toggled on, all team members (across all of your Coda workspaces) who attempt to add an unapproved Pack to a doc will be required to submit a request for approval. Each request will send an email to the org admins, and requests will aggregate in this same Packs approvals section of the admin settings for admin review and action. Check out the section below for more steps on this.

Any Packs enabled before toggling this setting on will remain enabled for your team unless you take action. You will see these Packs in this Pack approvals tab. They will be labeled with Enabled under their name.

Also note that when this setting is enabled, members that aren't part of your organization can no longer install Packs, and org admins can optionally configure granular policies to customize access and functionality of Packs.

Manage Packs requests

Once you’ve turned on the above setting to require Pack approvals, you’ll need to know how to view, approve, and reject Pack requests from your team. If you’re an org admin, just follow these steps:

Go to coda.io/workspace
Click on Admin settings in the upper left
Scroll to - or search for - the Pack approvals tab
Your Requests to review list will appear below the toggle from the previous section. Click the downward chevron to the right of the Pack name to expand and see your options.
From the expanded view, you can see who is requesting to use the pack (and why). Click the arrow icon to the right of the Pack name to see more information about the Pack.
To deny requests: Use the red Deny all request button to deny the Pack entirely, for all members. Or to deny individual requests, click the three dots to the left of the requester name, and click Deny request.
To approve the Pack: Use the blue Enable button to approve the Pack for everyone.
If you want to approve the Pack for only certain members of your org, or you want to approve only certain Pack functionality, you can do so by creating custom Pack configurations. Click on the down arrow next to the Enable button, and select Configure manually. Check out this article for all the details on adding these Pack configs.

A few important notes:

Once a Pack is approved it remains approved, even if the Pack changes scope.
When a Pack is approved, the default configuration allows all org members to use the full functionality of the Pack. If the Pack is sensitive, org admins can optionally change this configuration to only allow specific users or groups to use the Pack. See this article on advanced access controls for Packs

View enabled and disabled Packs

Beneath the Requests to review section, you will see several different tabs.

Packs you have configured or allowed: If you've already enabled Pack approvals, this tab will contain a list of Packs that have been approved for all users (or approved with a configuration). You can click the downward facing chevron to expand the details in order to get more information about any Pack, disable it, enable it, or add custom configurations.
- 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.
Packs used in your organization: This tab shows all Packs that have been installed 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.

A note for Pack Makers

For Pack Makers in a Enterprise workspaces wanting to test out a Pack you've built: If your org admin has required all Packs to be pre-approved before use (see above), then this will also apply to the Pack you're building. In other words, your admin may need to approve the Pack before you can test it out in a doc.

FAQs

How can I have even more granular control over how Packs are used in my org?

If you want even more refined control - beyond just requiring approval for Packs - check out this article on custom configurations for Packs. You can use these configs to control to control who in your org can use a Pack, and can even limit Pack functionality for those allowed users.

What's the difference between enabling Pack approvals and creating custom Pack configurations?

Enabling Pack approvals - as described in this article - will require all users in your org to explicitly request access to a Pack before they can use it. Admins then review these requests, and can either approve or deny them. Approving a Pack will approve it for all members in org, so control is less granular than Pack configs. This simple feature is a good way to know which Packs your org members actually want.

Creating Pack configurations, on the other hand, is a more granular way to pre-set who has access to which Packs, and what they can do with each Pack. You can proactively approve (or block) users from certain Packs and certain Pack functions. Each Pack can have as many configurations as needed, and you can even create user groups. For instance, you can allow everyone in the Engineering department full access to the Jira Pack, while granting only partial access to the Marketing team. Admins who use custom Pack configs - instead of Pack approvals - won't have to worry about reviewing and actioning every Pack request from users in their org. Learn all about Pack configurations here.

Do I need to enable Pack approvals in order to create Pack configurations?

No - enabling pack approvals and creating Pack configs are separate functionalities. You can utilize both, either, or neither for your org.

What does the process of requesting a Pack look like for members of my org?

Once you have enabled Pack approvals for your org: If an org members attempts to install a Pack that isn’t yet approved, they will see a large Request access button. When they click this, they’ll be prompted to write a quick note about why and how they want to use the Pack. They then hit Send request, and the org admins will be notified.