Skip to main content

​
Permissions & policies

Organizations need more than a member list. They need a predictable way to decide which resources and features a member can actually use.

​
Effective access

A member’s effective access can be influenced by multiple layers:
This means a role alone is not always enough to explain why a feature is visible or unavailable.

​
Organization policies

Organizations can use policy concepts to control shared behavior, such as:
  • which models members can use
  • whether developer access is allowed
  • whether FORGE is available
  • file and storage limits
  • research or search access
  • project creation rules
  • Knowledge management
  • organization billing behavior
The exact policy editor and available controls can evolve during Organizations 3.0 rollout.

​
Resource-level access

A member can belong to an organization without having access to every project or Knowledge source in it. Resource permissions create narrower collaboration boundaries inside the organization.

​
Overrides

Some Starfire systems support inherited/default behavior plus a narrower override. When an override exists, the interface should make it clear whether a value is:
  • inherited
  • explicitly allowed
  • explicitly denied
This prevents administrators from confusing a local exception with the organization default.

​
Deny vs unavailable

These are different conditions:
  • Unavailable — the platform, plan, or rollout does not expose the capability.
  • Denied — the capability exists but policy or permission blocks this user/context.
Troubleshooting should identify which layer is responsible before changing permissions.

​
Auditability

Sensitive organization changes should produce an administrative record when supported by the current build so operators can identify who changed membership, roles, billing, or important policy state.

Control Center RBAC

Learn how organization permissions differ from platform-wide administrator permissions.