access — permission sets overview

Permission Sets are the governance foundation of access control inside Neostella.

This Permission Sets tool acts as a permission constructor determining what users can view, create, edit, delete, or conditionally interact with. Permissions are established across multiple operational layers, including:

• Objects.
• System tools.
• Custom permissions.
• Assignees.

Rather than configuring access individually across tools, Permission Sets centralize governance into a structured model.

This tool is designed for administrator roles and serves as the baseline mechanism that controls how workspaces, such as Cases and Intake,  behave in terms of system access for roles, groups, and individual users.

how permission sets work

Permission Sets operate by grouping permissions into structured governance packages that can later be assigned to users or groups. Access is not managed tool by tool, but governed centrally through a unified permission framework.

Admins first define what actions should be authorized across different objects and system tools. These authorizations are then packaged into a Permission Set.

Once assigned, the system evaluates these permissions every time a user interacts with the Neostella determining what records they can access, what configurations they can modify, what workflows they can execute, and what administrative tools they can govern.
 

when to use this tool

Permission Sets should be used whenever structured access governance is required. Permission sets are assigned to users and groups, governance follows a defined preparation sequence:

1. Create users.
2. Organize users into groups (if applicable).
3. Configure permission sets.
4. Assign permission sets to users or groups.

This sequence ensures that access can scale efficiently. Instead of managing permissions individually, admins manage governance at the group or role level.
 

understanding the permission set hierarchy

Neostella includes core permission actions that can be configured across objects and system areas. These permissions define what level of interaction a user is authorized to perform.

Conditional (advanced configuration): Applies additional rules that limit or refine how core permissions are executed. This is not a standalone action but a conditional layer applied to other permissions.

In other words:

• Core permissions define what action a user can perform.
• Conditional permissions define under what circumstances that action is allowed.

permission logic hierarchy

Permissions follow a governance hierarchy where higher authorization implies lower-level capabilities. This creates the following functional dependency model:

View → Edit → Delete (dependency relationship)

In practical terms:

• Edit permission requires View permission.
• Delete permission requires Edit permission.
• As a result, a user cannot delete a record they cannot edit, and cannot edit a record they cannot view.

This dependency model ensures consistent governance and prevents contradictory access configurations.

Create operates as an authorization extension tied to a record generation. 

Conditional permissions introduce rule-based governance, where access depends on configured logic rather than static authorization.
 

how permissions appear

Permissions may appear in different interface formats depending on configuration context. Common display models include:

• Dropdown menus with hierarchical access levels (View, Edit, Delete)
• Checkbox authorizations (commonly used for Create)
• Binary (Yes / No) selections for system-enforced permissions

These varied controls do not represent different permission types. Instead, they provide different configuration mechanisms aligned with the level of contextual control required.
 

hierarchical permission levels

Beyond action-based permissions, Neostella also applies hierarchical access levels that define record scope. These levels determine how broadly a permission applies across objects.

hierarchical logic model

This hierarchical model also applies to access levels such as Any, Related, Own, and None. A more permissive scope cannot be assigned if the preceding permission is more restrictive. For example:

• If a user does not have View = Any, they cannot have Edit = Any.
• If a user has View = Own, they cannot have Edit = Related or Edit = Any.
• If a user has View = None, no Edit or Delete permissions can be granted.

In other words, the scope can never exceed the scope defined at the previous level. Each permission must remain equal to or more restrictive than the one that precedes it.