Support

Direct help for common BaseBuddy setup, access, mapping, editing, and deployment tasks.

Support/How to customize permissions on BaseBuddy

How to customize permissions on BaseBuddy

Add a narrow permission allow or deny for a project member when the built-in role is close but not exact.

Use permission overrides when a project member's role is almost right, but one action should be added or blocked.

Start with the closest built-in role. Roles are easier to review later, and most access changes should happen in Project SettingsMembers by opening the member's Manage access panel. Use Permissions only for a narrow exception.

Before you start

You need access to manage members and permissions for the project. In the default roles, owners and admins can manage normal member permissions.

Owners have extra safety controls. Only owners can change owner members or owner permissions, and only owners can grant or remove Delete project access. Admins cannot use overrides to cross those owner boundaries.

For the full role model, see Permissions and roles: how BaseBuddy handles them.

Choose role or override

Change the role when the person's main job has changed. For example, use Editor for someone who should edit and publish all content, Author for someone who should work only on assigned authored content, and Viewer for read-only access.

Use an override when the role is still the right starting point, but one permission needs a clear exception. For example, an editor who should edit all content but must not publish can stay an editor with publishing turned off in Permissions.

Do not use many overrides to build a hidden custom role. If several people need the same pattern, choose a role strategy your team can explain later.

Invite members screen with role choices and a safe placeholder email
Invite members screen with role choices and a safe placeholder email

Add or remove one permission

  1. Open the project.
  2. Select Project Settings in the sidebar.
  3. Open Permissions.
  4. In Members, select the member you want to update.
  5. Review their current role labels before changing anything.
  6. Find the permission under Project, Members, Mapping, Content, or Authors.
  7. Use the switch for the one permission you want to change.
  8. Review the status text under the permission.
  9. Select Save changes.
  10. Wait for BaseBuddy to show Permissions updated.
Permission controls for a project member with role defaults and overrides
Permission controls for a project member with role defaults and overrides

If you changed the wrong switch before saving, select Reset to return that member's permissions to the last saved state.

How the switch changes access

Each permission row shows how BaseBuddy is calculating that member's effective access.

StatusMeaning
From roleThe member gets this permission from their role.
Extra permission for this memberYou turned on a permission their role does not include. This is an explicit allow.
Removed for this memberYou turned off a permission their role includes. This is an explicit deny.
Not grantedThe role does not include this permission, and no override adds it.

Explicit deny wins. If a role includes a permission but the member has Removed for this member, BaseBuddy blocks that action for the member.

Publishing uses the same rule. If publish access is denied, the member cannot use Publish, Unpublish, or Archive, and cannot save a mapped status change that requires publish access. For the workflow behavior, see How to publish, unpublish, and archive content.

Keep owner boundaries intact

BaseBuddy protects owner access even when permission overrides are available.

Only owners can:

  1. Change owner members.
  2. Change owner permissions.
  3. Grant or remove Delete project access.

If an admin selects an owner in Permissions, the switches are disabled and BaseBuddy explains that only project owners can change owner permissions. If an admin selects Delete project for a non-owner member, BaseBuddy shows that only project owners can change delete access.

These limits prevent an admin from accidentally locking out the people responsible for the project or giving destructive project access without an owner.

Test the affected user

After saving an override, test with the member whose access changed, or with a test account that has the same role, overrides, and author scopes. Do not rely only on your owner or admin account.

  1. Sign in as the affected user.
  2. Open the project.
  3. Try the exact action you changed.
  4. Confirm actions with Removed for this member are blocked.
  5. If the change affects publishing, test Publish, Unpublish, Archive, and one normal save that changes mapped status.
  6. If the user has authored access, test assigned authored content and unrelated authored content.

If authored access is wrong, check author scopes before adding more overrides. Use How to assign author scope to a member for that flow.

If the result is not what you expected

Remove the override first, then check the base role. The role should still describe the person's normal project access.

If the person needs a different main role, update them from Project SettingsMembers instead. If they are not a member yet, create an invite with the right role and author scopes from Project SettingsInvite Members. See How to invite users to your BaseBuddy project.