Skip to main content

Permission Sets

Permission sets grant additional access on top of a user’s profile without changing that profile.

Keep profiles narrow and stable. Use permission sets and permission set groups to grant only the access users need:

  • Permission set: Grants permissions for a specific task, capability, or job function. A user can have multiple permission sets.
  • Permission set group: Bundles multiple permission sets for easier assignment to common roles or personas.

This keeps access easier to audit, maintain, and adjust as Cloudaware usage grows.

What Permission Sets Do​

A permission set is a bundle of settings and permissions that can be assigned to one or many users.

Permission sets can grant:

  • Object permissions, including create, read, update, and delete access.
  • Field-level security for visible and editable fields.
  • App and tab access.
  • Apex class access and other system privileges, where applicable.
  • Other feature permissions available in your Salesforce org.

Important behavior:

  • Permission sets are additive. They grant access on top of the profile.
  • Permission sets cannot remove permissions that the profile already grants.
  • If access should not be broadly available, do not place it in the baseline profile. Grant it through permission sets instead.

What Permission Set Groups Do​

A permission set group bundles multiple permission sets into a single assignment. Groups are typically aligned to a role, persona, or job function, such as Cloud Engineer, Security/GRC Analyst, FinOps Analyst, or Read-Only Stakeholder.

When you assign a permission set group to a user, the user receives the combined permissions from every permission set in the group. This reduces one-off assignments and makes access easier to review.

Permission set groups also support muting. Muting suppresses selected permissions from the group for all users assigned to that group. Muting does not remove permissions granted by the user’s profile or by another assigned permission set.

If you need repeatable exceptions, create a small number of group variants, such as Cloudaware: FinOps - No Exports.

  1. Start with a minimal baseline profile for each major user type, such as human users and service or integration users. See Profiles.
  2. Create module-scoped permission sets for Cloudaware capabilities, such as CMDB, Cost Management, Compliance Engine, Monitoring, or Vulnerability Management.
  3. Bundle permission sets into permission set groups aligned to personas, such as Administrators, Cloud Engineers, Security/GRC, FinOps, and Read-Only users.
  4. Assign access through IdP groups or automated provisioning where supported. Treat permission set assignment as part of joiner, mover, and leaver processes.
  5. Use Scoping & Sharing to control data visibility, such as production versus non-production records or account, subscription, and project boundaries. Do not create additional profiles only to manage data scope.

Naming And Structure​

Use descriptive and predictable names. Recommended naming patterns:

  • Permission sets: Cloudaware: <Module> - <Capability> (example: Cloudaware: Compliance - Manage Policies)
  • Permission set groups: Cloudaware: <Persona> (example: Cloudaware: FinOps)

Combine them through permission set groups instead of creating large, monolithic permission sets.

Examples Cloudaware Patterns​

Use these examples as reference patterns and tailor them to your org:

  • CMDB and Inventory: Edit normalization or mapping, manage tags, approve changes, and run ingestion jobs.
  • Cost and FinOps: Manage budgets, edit cost mappings, and perform cost export actions.
  • Compliance: Manage policies, run evaluations, manage evidence, and export reports.
  • Monitoring and Vulnerability Management: View findings, manage assignments, update remediation status, or export operational reports.
  • Read-only access: View list views, reports, dashboards, and object records without modifying data.

Known Access Limitations in Cloudaware CMDB​

Public CMDB list view creation is limited to users who meet one of the following conditions:

  • The user has the CloudAware Administrator profile.
  • The user has the CloudAware Collector Only profile.
  • The user has the listViewEditor custom permission.

See also: CMDB List Views.

Use this limitation as a governance pattern:

  • Put broad “editor” capabilities behind permission sets or custom permissions.
  • Keep profiles minimal; avoid granting write powers to wide audiences by default.

Recommendations​

Use these recommendations as a governance pattern:

  • Keep profiles minimal.
  • Put broad "editor" capabilities behind permission sets or custom permissions.
  • Avoid granting write or sharing capabilities to broad audiences by default.
  • Review users with public list view creation rights during access reviews.