Roles and permissions
Every person in your organization has a role. The role defines what they can see and change. RuleForge also lets you adjust access at the project level, in case someone needs a different level in a specific area.
Organization roles
Administrator
Full control. Manages members, integrations, identity, projects, publishing, and billing. Use sparingly.
Security content lead
Leads the editorial work. Creates projects, edits content, runs reviews, and publishes versions. Not focused on member or identity administration.
Reviewer
Analyzes and approves. Can comment, request changes, and approve reviews — but isn't the main author.
Engineer
Content author. Edits rules, creates cases, runs tests, and participates in reviews. Doesn't publish alone (depends on approval and the organization's flow).
Read only
Follows work without modifying anything. Useful for stakeholders or observers.
Per-project role
In addition to the organization role, each project can have its own roles. This is useful when someone needs less (or more) access in a specific project. For example: someone with Read only in the organization can be an Engineer on a pilot project.
How to pick the right role
Quick tips:
- Grant the smallest role that does the job.
- Use Administrator only for people who truly need to administer the organization.
- If you're torn between Engineer and Reviewer, ask "does this person write content or just approve it?".
- For guests from other teams (observers), Read only is usually enough.
Practical rules
- A person can be in multiple organizations and have different roles in each.
- Invitations and automatic provisioning (SCIM) respect the role you define.
- After changing a role, the person needs to reload the page to see the change.