Groups and Folders
As a workspace grows past a handful of scripts and flows, access control stops being “who can log in” and becomes “who can touch this specific item.” Orvanta splits that problem into two complementary mechanisms: folders group items and carry the permissions, groups bundle users so you assign access once instead of per person.
Folders
Section titled “Folders”A folder is a namespace for related items — scripts, flows, connections, schedules — that carries its own role-based permissions. Put a project’s items in one folder and grant access at the folder level rather than repeating the same grant on every item inside it.
Subfolders
Section titled “Subfolders”Orvanta supports nested folder structures by using forward slashes in item paths, similar to filesystem organization. Only top-level folders enforce inherited permissions.
Groups
Section titled “Groups”A group is a named set of users. Add a group to a folder once and every member inherits that folder’s access — add or remove a user from the group instead of editing every folder they touch. Users can belong to more than one group at a time. Each group receives one of three permission levels on a given folder:
- Viewer: read-only access
- Writer: read and write access
- Admin: read/write access plus permission management capabilities
Combined usage
Section titled “Combined usage”Groups nest inside folders, not the other way around: a folder’s permission list can reference individual users or whole groups, but a group can’t contain a folder. In practice, grant folder access to a group whenever more than one person needs the same level of access, and reserve individual grants for one-off exceptions.
Instance groups
Section titled “Instance groups”Instance groups are provisioned automatically via SCIM (System for Cross-domain Identity Management) from an identity provider such as Okta or Azure Active Directory, so instance admins don’t have to create and maintain groups by hand across workspaces. Unlike workspace groups, an instance group can carry an instance-level role — superadmin or devops — and when a user lands in multiple instance groups with different roles, the higher role wins.