# Configure Your First Permission Groups | Kizen Basics

## Overview

In <code class="expression">space.vars.Kizen\_company\_name</code>, a **Permission Group** defines what your team members can see and do across your workspace, from top-level features like <code class="expression">space.vars.dashboards</code> and <code class="expression">space.vars.automations</code>, down to individual fields on a <code class="expression">space.vars.entity</code>. By default, a new <code class="expression">space.vars.object</code> 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 <code class="expression">space.vars.Theme\_park\_name</code>:

* **Create a permission group** called *Flywheel Guest Staff* from the Settings area
* **Apply a permission set** to the Tickets <code class="expression">space.vars.object</code> so that group can access ticket <code class="expression">space.vars.entities</code>

### 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 <code class="expression">space.vars.entities</code> they shouldn't
* <code class="expression">space.vars.automations</code> 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 <code class="expression">space.vars.workflows</code> running as intended.

***

## Before You Begin

Before creating a permission group, you must have the following:

* **Admin access** to your <code class="expression">space.vars.Kizen\_company\_name</code> workspace. Only Admins can access the Settings area and manage permission groups.
* **Your Objects already created.** The Add Permission Group modal lists all existing <code class="expression">space.vars.objects</code>, including Tickets, Concessions, and Ride Waivers. Create these <code class="expression">space.vars.objects</code> before building your group. If you haven't created your <code class="expression">space.vars.objects</code> yet, see [Create Your First Object](/docs/kizen-basics/kizen-in-action/create-your-first-object-or-kizen-basics.md) before continuing.

{% hint style="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.
{% endhint %}

***

## Business Settings Capabilities by Role

In <code class="expression">space.vars.Kizen\_company\_name</code>, 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 <code class="expression">space.vars.object</code>-level permissions | ✅     | ❌                    | ❌                         |
| Access Settings area                                                          | ✅     | ❌                    | ❌                         |
| Access Tickets <code class="expression">space.vars.object</code>              | ✅     | ✅                    | ❌                         |
| Access Concessions <code class="expression">space.vars.object</code>          | ✅     | ❌                    | ✅                         |
| Edit associated <code class="expression">space.vars.entities</code>           | ✅     | Tickets only         | Concessions only          |
| Delete or archive <code class="expression">space.vars.entities</code>         | ✅     | ❌                    | ❌                         |
| Export <code class="expression">space.vars.entities</code> to CSV             | ✅     | ❌                    | ❌                         |

***

## Create the Flywheel Guest Staff Permission Group

{% stepper %}
{% step %}

#### In the top navigation, select **Settings**.

Select **Team, Roles, & Permissions**.
{% endstep %}

{% step %}

#### Select the **Permission Groups** tab.

Select **New Permission Group**.

<div data-with-frame="true"><figure><img src="/files/OrnZPLS9VjdbaNpvEGJI" alt="" width="563"><figcaption></figcaption></figure></div>

The **Add Permission Group** modal opens. This is where you'll name your group and configure its access to every area of <code class="expression">space.vars.Kizen\_company\_name</code>, including top-level features and each of your <code class="expression">space.vars.objects</code>.
{% endstep %}

{% step %}

#### Name Your Permission Group

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

<div data-with-frame="true"><figure><img src="/files/B8NBtjNpqPghhJyEVcVg" alt="" width="563"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

#### Turn on Feature-Level Permissions

The modal displays every area of <code class="expression">space.vars.Kizen\_company\_name</code> the group can access, each with a toggle to enable or disable access. Some areas, like Homepage, <code class="expression">space.vars.object</code> 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 <code class="expression">space.vars.object</code> - Tickets | On      |
| Teams - My Profile                                                 | On      |
| {% endstep %}                                                      |         |

{% step %}

#### Configure Permission Set

When you toggle **Custom Object - Tickets** on, the <code class="expression">space.vars.object</code> expands to reveal its full permission set. Configure the permissions as the following (there should be nothing past the **Create/Edit** level):

<div data-with-frame="true"><figure><img src="/files/wh6N6A2Z9MuMaQYjVhPf" alt="" width="563"><figcaption></figcaption></figure></div>

<div data-with-frame="true"><figure><img src="/files/Md6a2RQRUioR0konPBuA" alt="" width="563"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

#### Save Permission Group

Once all settings are configured, select **SAVE.**
{% endstep %}
{% endstepper %}

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 <code class="expression">space.vars.Theme\_park\_name</code> Guest Staff and the Tickets <code class="expression">space.vars.object</code> are configured, use the same steps to create a second permission group called Flywheel Concession Staff and configure its access to the Concessions <code class="expression">space.vars.object</code>.

### 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 |
| --------------------------------------------------------------- | ------- |
| <code class="expression">space.vars.object</code> - 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:

<div data-with-frame="true"><figure><img src="/files/EQXD2BSS9zujjtgzzOOb" alt="" width="563"><figcaption></figcaption></figure></div>

<div data-with-frame="true"><figure><img src="/files/24rB18GfXIeYdrz2BEMS" alt="" width="563"><figcaption></figcaption></figure></div>

***

## How This Fits Into Agentic Workflows

<code class="expression">space.vars.automations</code> 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 <code class="expression">space.vars.automation</code> assigns a <code class="expression">space.vars.entity</code> or task to a team member, their permission group determines what they can actually do with it. Getting this right before you build your <code class="expression">space.vars.automations</code> means the handoff works as intended every time.

For example:

* If a ticket purchase triggers an <code class="expression">space.vars.automation</code> 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 <code class="expression">space.vars.entities</code> enabled for the <code class="expression">space.vars.entity</code> 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 <code class="expression">space.vars.automations</code> 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.

{% tabs %}
{% tab title="Insurance" %}
In **insurance**, separate permission groups ensure that claims staff, underwriters, and account managers each see only the <code class="expression">space.vars.objects</code> and fields relevant to their work.

* A Claims Adjuster group might have Create/Edit access on claim <code class="expression">space.vars.entities</code> 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 <code class="expression">space.vars.objects</code> 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
  {% endtab %}

{% tab title="Healthcare" %}
In **healthcare**, permission groups protect patient <code class="expression">space.vars.entities</code> and ensure staff only access data relevant to their care responsibilities.

* An Intake Staff group might have access to intake form and appointment <code class="expression">space.vars.objects</code> but no visibility into care plan or billing <code class="expression">space.vars.entities</code>
* A Billing group might have access to charge and transaction <code class="expression">space.vars.objects</code> but no access to clinical documentation
* Field-level restrictions ensure sensitive data like diagnosis codes or treatment notes are visible only to clinical roles
  {% endtab %}

{% tab title="Financial Services" %}
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 <code class="expression">space.vars.objects</code>, with no access to investment or account management data
* A Compliance group might have View-only access across all <code class="expression">space.vars.objects</code> for audit purposes, without the ability to edit or delete any <code class="expression">space.vars.entities</code>
* Keeping Export to CSV disabled for most groups prevents unauthorized extraction of client financial data
  {% endtab %}
  {% endtabs %}

***

## What's Next

Now that your permission groups are created and your Tickets and Concessions <code class="expression">space.vars.objects</code> have permissions configured, you're ready to continue building out your workspace. [Create Your First Workflow](/docs/kizen-basics/kizen-in-action/create-your-first-workflow-or-kizen-in-action.md) to create an <code class="expression">space.vars.object</code> that goes through stages.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.kizen.com/docs/kizen-basics/kizen-in-action/configure-your-first-permission-groups-or-kizen-basics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.