RevoEngine Documentation

Groups collect users and Service Accounts for resource-level ACLs. They answer which principals may access this restricted resource. They do not grant platform capabilities by themselves; use Permissions for reusable role sets.

Create a Group

Open Groups, select Add, and provide:

Field	Required	Purpose
Name	Yes	Clear business or security-boundary name.
Category	No	Groups related access sets in the UI.
Description	No	Scope, approver, and intended resources.
Owner type	Yes	`USER` or `GROUP`.
Owner	Yes	Accountable user or parent ownership group.
Metadata	No	Searchable ownership, review, system, or environment attributes.

After saving, reopen the Group and use Members to add or remove users and Service Accounts. A Group avatar can be uploaded for discovery; the UI accepts JPG, JPEG, PNG, GIF, or WEBP up to 5 MB.

Apply a resource ACL

principal has FILE_READ
  + principal belongs to Finance Documents
  + folder ACL allows Finance Documents
  = principal can read that restricted folder

The same user without FILE_READ still cannot download. A user with FILE_READ but outside the allowed Group still cannot enter the restricted branch. For hierarchical Storage, a restricted ancestor continues to constrain descendants. Adding a user to a child-oriented Group cannot bypass an ancestor they are not allowed to access.

Group design patterns

Pattern	Example
Business domain	`Finance Operations`, `Customer Support EU`
Application boundary	`Checkout Production Readers`
Data sensitivity	`Payroll Restricted`
Workload access	`Settlement Service Accounts`

Avoid Groups named only Admins, Team 1, or Temporary. The name should still explain the boundary during an access review six months later.

Ownership and nesting

Owner type expresses accountability. A Group-owned Group is useful when a platform team owns several access sets, but it should not be mistaken for automatic member inheritance unless the target ACL and current membership explicitly provide it. Use metadata to record an approver, review cadence, ticket reference, and environment. Do not encode credentials or sensitive personal data in Group metadata.

Lifecycle and roles

Action	Role
List and inspect	`USER_READ`, `USER_WRITE`, or `USER_ADMIN`
Create, edit, and manage members	`USER_WRITE` or `USER_ADMIN`
Delete	`USER_ADMIN`
Restore	Authorized user administration access

Delete is recoverable. Before deleting, search for Tables, Views, Storage entries, and other resources that reference the Group. Removing the boundary without replacing it can either block workloads or produce an unintended access-policy change.

Quarterly review

Confirm the owner is still accountable.
Export or inspect current members.
Remove inactive identities and obsolete Service Accounts.
Review every restricted resource referencing the Group.
Verify members also have the minimum platform role required.
Record the next review in metadata or your governance system.

Production checklist

Name the protected business or application boundary.
Set an accountable owner.
Keep human and workload membership explainable.
Pair Group ACLs with least-privilege platform roles.
Review restricted ancestors in Storage.
Find resource references before deleting a Group.

See Identity and access and Permissions.

​Create a Group

​Apply a resource ACL

​Group design patterns

​Ownership and nesting

​Lifecycle and roles

​Quarterly review

​Production checklist