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.

circle-info

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.

Capability
Admin
Flywheel Guest Staff
Flywheel Concession Staff

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

1

In the top navigation, select Settings.

Select Team, Roles, & Permissions.

2

Select the Permission Groups tab.

Select New Permission Group.

The Add Permission Group modal opens. This is where you'll name your group and configure its access to every area of Kizen, including top-level features and each of your Objects.

3

Name Your Permission Group

At the top of the modal, enter Flywheel Guest Staff.

4

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:

Area
Setting

Custom Object - Tickets

On

Teams - My Profile

On

5

Configure Permission Set

When you toggle Custom Object - Tickets on, the Object expands to reveal its full permission set. Configure the permissions as the following (there should be nothing past the Create/Edit level):

6

Save Permission Group

Once all settings are configured, select SAVE.

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:

Area
Setting

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


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?