Configure Your First Permission Groups | Kizen Basics
Overview
In Kizen, a Permission Group defines what your team members can see and do across your workspace, from top-level features like Dashboards and Agentic Workflows, down to individual fields on a Record. By default, a new Object is not accessible by any permission group except the Administrator. You must explicitly create a group and apply a permission set to it for your team to gain access.
In this walkthrough, you'll complete two tasks for Flywheel Adventure Park:
Create a permission group called Flywheel Guest Staff from the Settings area
Apply a permission set to the Tickets Object so that group can access ticket Records
Why This Matters
Permission groups define who can interact with your data and how. Skipping this setup, or doing it after your team is already working, can cause issues such as:
Team members accessing or editing Records they shouldn't
Agentic Workflows routing work to users without the access needed to act on it
Bulk actions like exporting or archiving being performed by unauthorized staff
Sensitive field data being visible to the wrong people
A well-configured permission group protects your data and keeps your Workflows running as intended.
Before You Begin
Before creating a permission group, you must have the following:
Admin access to your Kizen workspace. Only Admins can access the Settings area and manage permission groups.
Your Objects already created. The Add Permission Group modal lists all existing Objects, including Tickets, Concessions, and Ride Waivers. Create these Objects before building your group. If you haven't created your Objects yet, see Create Your First Object before continuing.
Note: You can create and configure a permission group before adding team members. Team members can be assigned to the group at any time.
Business Settings Capabilities by Role
In Kizen, only Admins can access and configure the Settings area. All other roles interact with the workspace within the boundaries Admins define.
Create and manage permission groups
✅
❌
❌
Configure Object-level permissions
✅
❌
❌
Access Settings area
✅
❌
❌
Access Tickets Object
✅
✅
❌
Access Concessions Object
✅
❌
✅
Edit associated Records
✅
Tickets only
Concessions only
Delete or archive Records
✅
❌
❌
Export Records to CSV
✅
❌
❌
Create the Flywheel Guest Staff Permission Group
Turn on Feature-Level Permissions
The modal displays every area of Kizen the group can access, each with a toggle to enable or disable access. Some areas, like Homepage, Object Settings, Notification Center, Teams, and App Marketplace, also include granular Permission Area controls with None, View, Create/Edit, and Delete/All options.
Enable only the following for Flywheel Guest Staff, and leave everything else off:
Custom Object - Tickets
On
Teams - My Profile
On
Your new group will now appear on the Permission Groups tab alongside the default Admin group. The table displays a Permission(s) Summary, User Count, and Role Count for each group, making it easy to confirm the group was created correctly.
Apply What You've Learned
Now that Flywheel Adventure Park Guest Staff and the Tickets Object are configured, use the same steps to create a second permission group called Flywheel Concession Staff and configure its access to the Concessions Object.
Create the Flywheel Concession Staff Permission Group
Follow the same steps in to create a new permission group. Name it Flywheel Concession Staff and enable only the following, leaving everything else off:
Object - Concessions
On
Teams - My Profile
On
Apply a Permission Set to the Concessions Object
Configure the following permission sets: All Concessions Records, Record Overview, Perform Single Record Actions, Perform Bulk Actions, Individual Concessions Field Permissions, Concession Info
Align it with the permission set of Flywheel Guest Staff; the difference is, you're configuring the Custom Object - Concessions instead of Custom Object - Tickets, so there will be some different permissions to configure.
Once complete, select SAVE.
When you're finished, it should look like this:
How This Fits Into Agentic Workflows
Agentic Workflows in Kizen run independently of permission groups; they execute regardless of a user's access level. Where permissions matter is after the handoff: when an Agentic Workflow assigns a Record or task to a team member, their permission group determines what they can actually do with it. Getting this right before you build your Agentic Workflows means the handoff works as intended every time.
For example:
If a ticket purchase triggers an Agentic Workflow that asks guest staff to verify admission status, they can update that field only if their permission group allows Create/Edit access on it
If concession staff need to log a purchase mid-visit, their group must have Create New Concessions Records enabled for the Record to save correctly
If concession staff shouldn't be able to export purchase data — protecting guest spending information — leaving Export to CSV set to None enforces that boundary automatically
Well-configured permission groups mean your Agentic Workflows run without hitting access errors, and your data stays protected at every step.
Tying It Back to Your Industry
Configuring permission groups is a requirement across regulated and operationally complex industries, and not just theme parks. Below are examples of how this setup translates into real-world use cases.
In insurance, separate permission groups ensure that claims staff, underwriters, and account managers each see only the Objects and fields relevant to their work.
A Claims Adjuster group might have Create/Edit access on claim Records they are associated with, but View-only access on all claims, which prevent cross-account edits
An Underwriting group might have access to policy and application Objects but no access to claims data
Sensitive fields like settlement amounts or fraud flags can be restricted to None for front-line staff while remaining visible to managers
In healthcare, permission groups protect patient Records and ensure staff only access data relevant to their care responsibilities.
An Intake Staff group might have access to intake form and appointment Objects but no visibility into care plan or billing Records
A Billing group might have access to charge and transaction Objects but no access to clinical documentation
Field-level restrictions ensure sensitive data like diagnosis codes or treatment notes are visible only to clinical roles
In financial services, permission groups enforce the access boundaries required for compliance and client data protection.
A Loan Officer group can be scoped to loan application Objects, with no access to investment or account management data
A Compliance group might have View-only access across all Objects for audit purposes, without the ability to edit or delete any Records
Keeping Export to CSV disabled for most groups prevents unauthorized extraction of client financial data
What's Next
Now that your permission groups are created and your Tickets and Concessions Objects have permissions configured, you're ready to continue building out your workspace. Create Your First Workflow to create an Object that goes through stages.
Last updated
Was this helpful?