---
title: Permission Policies | PostGrid
description: How to create permission policies that grant users an additional set of roles scoped to the organizations you choose, and assign them to the users who need that access.
---

A permission policy is an additional grant of access: it bundles a set of roles and scopes them to the organizations you choose. Assigning a policy to a user leaves the roles on their own account untouched — the policy’s roles apply only while they are acting on an organization that policy covers.

This lets you delegate access to a sub-organization without giving someone the “Admin” role, which would grant access to every sub-organization as well as to your own organization’s settings.

A support agent who needs to look up mail for one client, or a designer who maintains templates for a handful of sub-organizations, are both good candidates for a policy.

Permission policies are available once impersonation is enabled for your organization. If you don’t see **Permission Policies** in the left navigation, reach out to your account manager to get access.

## Creating a permission policy

Go to **Settings → Permission Policies** in the left navigation and click **Create Policy**.

![Permission Policies page in the PostGrid dashboard listing one policy, with the Create Policy button in the top right](/_astro/01-permission_policies.BU4sV-HV_1WJkcq.webp)

Fill in the three parts of the form:

1. **Description** — how the policy is identified throughout the dashboard, so name it after the access it grants (for example, “Read-only access for support team”).
2. **Organizations** — choose **All sub-organizations** to cover every sub-organization you have now and any you create later, or **Specific sub-organizations** and then **Select Sub-Organizations** to pick them individually. Selected sub-organizations appear as chips you can remove.
3. **Roles** — the roles a user assigned this policy takes on while acting as those sub-organizations. Pick the narrowest set that covers what they need to do. As when assigning roles to a user, **Live** and **View Only** only modify another role, so each must be paired with a base role such as Developer or Sender.

![Create Permission Policy form with a description entered, Specific sub-organizations selected with one sub-organization chosen, and a checkbox beside each available role](/_astro/02-permission_policies.wQLkf0qR_dmM1M.webp)

Click **Create** to save the policy. It has no effect until you assign it to a user.

## Assigning a policy to a user

Go to **Users**, open the user you want to grant access to, and click **Manage Policies** in the **Permission Policies** section. Select the policies to assign and confirm. The section then lists the policies the user holds, each with a **Remove** action.

![Permission Policies section on a user's page in the PostGrid dashboard, with a Manage Policies button and one assigned policy listed alongside a Remove action](/_astro/03-permission_policies.6Hoi724l_2uWTl4.webp)

The user takes on each policy’s roles the next time they impersonate one of the sub-organizations it covers. See [Impersonating your Sub-Organizations](/print-and-mail/dashboard/partnership/impersonating-your-sub-organizations/index.md) for how they use that access from the dashboard or the API.

A few notes on assignment:

- Policies cannot be assigned to admin users, since admins can already impersonate every sub-organization. The **Manage Policies** button is disabled on their profile.
- A user can hold several policies. Where two policies cover the same sub-organization, the user receives the combined roles of both.
- Users who have not yet completed their invite cannot be assigned policies. Assign the policy once they have accepted.

## Managing existing policies

The **Permission Policies** page lists every policy in your organization with its description, roles, sub-organizations, and creation date.

Policies cannot be edited after they are created. To change the roles or sub-organizations a policy covers, create a replacement and delete the original.

Deleting a policy removes it from every user it was assigned to, so a user left with no other policy covering a sub-organization loses access to it immediately.