> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/create-and-test-a-custom-role.md). # Create and test a custom role Build a least-privilege role, review its impact, and publish a safe replacement for an existing role. Podigee Audio Video Ad Server lets a workspace administrator create a role for a job that does not fit a standard role. After the first mention, this article uses Podigee Ad Server for the product name. A custom role is a named set of approved permissions. It does not bypass access scope, review rules, or workspace separation. Use a custom role when a standard role is too broad or does not contain the exact actions that a person needs. Use the smallest permission set that completes the job. ## Before you start * You have access to **Monetization > Monetization settings > Roles**. * You have permission to publish custom roles. * You know the job the role must support. * You know the person or group that will receive the role. * You know the scope where the role must work. ## Create the role 1. Open **Monetization > Monetization settings > Roles**. 2. Select **Create custom role**. 3. Enter a short role name that describes the job. 4. Enter a description that states what the role may do and what it must not do. 5. Select the permissions needed for the job. 6. Read the risk and protected-action hint for each permission. 7. Check the assignment impact shown by the form. 8. Review the role name, description, and complete permission list. Do not select a permission because it sounds useful later. Add it only when the person needs it for the defined job. Keep finance, access management, policy, and delivery authority separate unless one person must perform all of those responsibilities. ## Test the permission set before publishing Use a representative person and scope to check the role. Confirm that the role can complete the normal job and cannot perform an unrelated high-impact action. Check these cases: * The normal task can be opened and saved. * The task is limited to the selected workspace or records. * A record outside the scope is not visible or editable. * A protected action is unavailable when it is not in the role. * A review rule still applies when the role submits a high-impact change. * The person can read the receipt and evidence needed for the job. If the role is too broad, remove the permission and test again. If it cannot complete the job, add one approved permission at a time. Do not use a second broad role to compensate for a missing permission. ## Review and publish 1. Check the role name and description. 2. Check every selected permission and its risk. 3. Check the current assignment count. 4. Check the added and removed permissions when you edit an existing role. 5. Complete the configured review rule or solo confirmation. 6. Select **Publish custom role**. 7. Keep the completion receipt. ![The current One Podigee role assignment review shows the selected role, scope, and review confirmation before saving access.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-90be7c265fb3151f1de1e88e8d4450beda7d975e%2Fdoc-monetization-017-review-role-assignment.png?alt=media) *Review the permission decision and its scope before you publish or assign the role.* Publishing creates a new saved role version. It does not rewrite the old version. Existing assignments continue to use their saved version until you change or replace the assignment. ## Replace an existing custom role safely When the job changes, open the existing role and create the new permission set. 1. Select the custom role. 2. Choose **Edit**. 3. Update the description and permissions. 4. Review the assignment impact. 5. Test the new set against the normal job and a forbidden action. 6. Complete the configured review. 7. Select **Publish custom role**. 8. Change assignments only after the new version is verified. Keep the old version when it is still needed for current work or audit evidence. The role version, permission digest, assignments, and review result must remain reconstructable. ## Assign the role After the role is published, use [Assign a standard role](/documentation/grow-and-monetize/monetization/assign-a-standard-role.md) for the People and access workflow. The custom role appears with the other published role options. Select the person, role version, access scope, and access period together. Do not give the role an entire workspace when the job needs only selected records. The role answers what the person can do. The scope answers where they can do it. ## If the role is not safe to publish * **The permission list is too broad:** remove unrelated permissions and test again. * **The role has assignments:** publish a successor version. Do not mutate the version already used by current work. * **The impact count is unexpected:** stop and inspect the current assignments before publishing. * **The review is required:** complete the review or ask the configured reviewer to decide. * **A task still fails:** add only the missing approved permission, then repeat the test. * **You cannot publish:** ask a workspace administrator to grant role-publish permission. ## Expected result The published role has a clear purpose, a tested permission set, an explicit scope boundary, and a visible review result. People receive only the actions and records needed for their work. Earlier role versions and assignments remain available for safe change and audit. ## Next useful tasks Use [Add, change, revoke, or restore user access](/documentation/grow-and-monetize/monetization/add-change-revoke-or-restore-user-access.md) to assign the role. Use [Complete the required reviews](/documentation/grow-and-monetize/monetization/complete-the-required-reviews.md) when the workspace policy requires an independent review. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/create-and-test-a-custom-role.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.