Roles and permissions

Access is granted by permissions, grouped into roles, assigned to people. Each product keeps its own roles, so a person can be an administrator in one and a viewer in another.

Built-in roles

Typical roles include Owner (full control, including billing and connections), Administrator, Security, FinOps, Operator and Viewer. Each maps to a set of permissions such as managing connections, approving remediations, publishing reports or only reading.

Least privilege

Assign the narrowest role that lets someone do their job. Sensitive capabilities — approving a change, managing connections, turning on remediation — are separate permissions, so you can grant read access widely and keep approval rights with a few people. This also enables four-eyes: the person who requests a change cannot be the person who approves it.

Permission-gated actions

Every action in the product checks a permission before it runs, and the same check governs API tokens: a token can only ever carry a subset of its owner’s permissions. Denied actions are recorded in the audit trail.

Assigning roles

In the CloudVision360 portal, administrators assign each person the apps they may open and their role in each one, so one place decides who can do what everywhere. Inside a product, people are under Admin at the bottom of the icon rail: CloudVision360 Users & access, ITOps360 Settings → Users & roles, AgentVision360 Settings → People, BackupVision360 Users. With single sign-on you can map identity-provider groups to roles so membership is applied automatically at each sign-in.

MSP access

Service-provider staff use act-as sessions into customer tenants rather than standing roles. See architecture and tenancy.