# Create Your First Workflow Object | Kizen Basics

## Overview

{% hint style="warning" %}
**Caution:** This setup reflects <code class="expression">space.vars.Kizen\_company\_name</code>'s default configuration. Your administrator may have customized your layout, so columns or navigation may appear differently. Trial accounts may have limited features.
{% endhint %}

The Reyes family has been enjoying their visit to <code class="expression">space.vars.Theme\_park\_name</code>. Later in the day, Elena realizes she left her backpack near one of the roller coaster rides. Marcus reports the lost item to guest services, and a staff member creates a **Lost Item Request** to track the search.

As park staff investigate, the request moves internally through several stages: **Reported**, **Searching**, **Located,** **Resolved,** and **Not Found**.

Processes like this are managed in <code class="expression">space.vars.Kizen\_company\_name</code> using a **Workflow Object**.

A Workflow <code class="expression">space.vars.object</code> tracks how work progresses through a structured process. Instead of Records simply storing information, they move through defined **stages** that represent milestones in the lifecycle of a task.

In this walkthrough, you’ll create a **Lost Item Requests Workflow Object** that allows <code class="expression">space.vars.Theme\_park\_name</code> staff to track lost items reported by park visitors.

You will:

* Create a new <code class="expression">space.vars.object</code>
* Enable the **Contains Workflow** setting
* Configure stages that represent the lost item process

This Workflow <code class="expression">space.vars.object</code> will allow <code class="expression">space.vars.Theme\_park\_name</code> staff to track operational requests and ensure the right team members take action at the right time.

### Why This Matters

Workflows transform <code class="expression">space.vars.objects</code> from **data containers** into **operational processes**.

Without workflows, <code class="expression">space.vars.entities</code> only store information. With workflows enabled, Records move through a structured lifecycle that teams can track and manage.

Clear workflow design helps prevent issues such as:

* Staff losing visibility into operational tasks
* Requests becoming stuck without clear ownership
* <code class="expression">space.vars.automations</code> triggering at the wrong time
* Reporting failing to reflect real operational progress

A well-designed Workflow ensures that work moves consistently through your organization and that teams always understand **what stage a task is in**.

### Before You Begin

Before creating a Workflow <code class="expression">space.vars.object</code>, make sure you have the following:

* **Admin or Technical Builder permissions**
* A **Business workspace created**
* Access to **Data** > **Custom Objects** in your navigation

Workflow <code class="expression">space.vars.objects</code> are best used when work follows a **repeatable lifecycle**, such as service requests, approvals, onboarding processes, or operational tasks.

***

## Create Your Workflow

{% stepper %}
{% step %}

#### Navigate to **Objects**

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

1. In the top navigation, select **Data**.
2. Choose **Custom Objects**.

You will be taken to the <code class="expression">space.vars.objects</code> page.
{% endstep %}

{% step %}

#### Select **NEW OBJECT**

{% hint style="info" %}
**Note:** Admins and technical builders with the correct permissions will see the full creation interface.
{% endhint %}
{% endstep %}

{% step %}

#### Fill out the **General Settings** page

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

For this example, enter the following:

* **Object Name:** Lost Item Requests
  * This is the name of the Object that stores requests submitted by guests or staff when an item is reported missing.
* **Record (Entity) Name:** Lost Item Request
  * This is the name used to describe an individual Record in the Object.
* **Contains Workflow:** Enable
  * Enabling this setting converts the Object into a **Workflow Object**, allowing Records to move through defined stages that represent progress in the process.
* **Enable Quick Filters:** Disable
* **Object Description:** Tracks lost item reports submitted by guests and staff. Each request moves through stages such as Reported, Searching, and Resolved as staff investigate and recover items.
* **Enable Activities:** Enabled
* **Track Entity $ Value:** Disabled
  {% endstep %}

{% step %}

#### Select **SAVE & CONTINUE**

This will automatically save your <code class="expression">space.vars.object</code> and take you to the Stage Settings&#x20;
{% endstep %}

{% step %}

#### Configure Stage Settings

This is where you define the lifecycle stages that each **Lost Item Request** will move through as staff investigate the missing item.

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

At the top of the page, you will see two workflow configuration options.

#### % Chance to Close

**Disable** this setting.

This feature allows each pipeline stage to be assigned a probability value, which is used to forecast the likelihood of closing a deal. It's most commonly used in sales environments to predict revenue. Since we're setting up a ticket system to track lost items — not managing sales — this feature isn't needed and can safely be disabled without any impact to your workflow.

When the "Please Confirm Modification" dialog appears, click **CONFIRM**. You won’t need the % Chance to Close setting for this example.

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

#### Use AI to Update Stage %

Leave this setting **disabled**.

This feature allows the system to automatically adjust stage probability values based on historical workflow performance. Since the Lost Item Request process does not require forecasting, this setting is not needed for this example.
{% endstep %}

{% step %}

#### Add a Reported Stage

Next, add the **Reported** stage. This stage represents when a guest first reports a missing item.

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

In the **Stages** table:

* Locate **Stage 1** in the Stage Name field.
* Rename it to **Reported**.

Leave the default stage values.

* **Stage Status:** Open
  {% endstep %}

{% step %}

#### Add a Searching Stage

This stage indicates that park staff are actively searching for the item.

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

Select **+ ADD STAGE**.

Enter the following values:

* **Stage Name:** Searching
* **Stage Status:** Open

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

{% step %}

#### Add a Located Stage

This stage indicates that the missing item has been found but has not yet been returned to the guest.

Select **+ ADD STAGE** again.

Enter the following values:

* **Stage Name:** Located
* **Stage Status:** Open

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

{% step %}

#### Add a Resolved Stage

This stage represents when the item has been successfully returned to the guest or the request has been completed.

Select **+ ADD STAGE**

Enter the following values:

* **Stage Name:** Resolved
* **Stage Status:** Won

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

{% step %}

#### Add a Not Found Stage

This stage represents when the item hasn't been found, and the loss is considered permanent.

* Select **+ ADD STAGE** one more time.
* Enter the following values:
  * **Stage Name:** Not Found
  * **Stage Status:** Lost

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

{% step %}

#### Review Your Workflow

Make sure the stages appear in the following order:

1. **Reported**
2. **Searching**
3. **Located**
4. **Resolved**
5. **Not Found**

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

You can reorder stages by dragging the **six-dot handle** on the left side of each stage row. The order determines how the workflow appears in **Board View** and how progress is tracked in reports. Learn more about Board View with [Moving Through Your Workflow](/docs/kizen-basics/kizen-in-action/move-through-your-workflow-or-kizen-basics.md).

Select **SAVE & CONTINUE** in the upper-right corner.

{% hint style="info" %}
**Note**: The **Reasons Lost** and **Reasons Disqualified** sections will remain unavailable unless you add a stage with the **Lost** or **Disqualified** status.
{% endhint %}
{% endstep %}
{% endstepper %}

You will then move to **Step 3: Related Objects**, where you can define relationships between the Lost Item Requests Object and other Objects in your workspace. For this example to work correctly, configure the following settings before moving on:

* **Team Associations**
  * Set *Where does this object get its team associations?* to **Direct**
* **Primary Relationships** Under *This Object has Primary Relationships*, add a related object with the following settings:
  * **Related Object:** Contacts
  * **Relationship Type:** Many-to-One
  * **Relationship Name:** Primary Contact Record
  * **Reverse Relationship Name:** Related Lost Item Records
  * **Share Timeline To Related:** On
  * **Share Timeline From Related:** On

All other toggles (**Share Lead Sources To Related**, **Share Lead Sources From Related**, **Suppress Related Field**) should remain turned off.

You have now setup a Workflow object. For more information on how to set up your other object settings, see [Create Your First Object](/docs/kizen-basics/kizen-in-action/create-your-first-object-or-kizen-basics.md).

***

## How This Fits Into Agentic Workflows

Object Workflows define **how work progresses**, while Agentic Workflows **define what happens when that work progresses**. For example:

* When a **Lost Item Request** moves to **Reported**:
  * Guest services staff are notified
  * A task is assigned to park operations
* When the request moves to **Located**:
  * Staff are prompted to contact the guest
  * A pickup location can be arranged
* When the request moves to **Resolved**:
  * The request is archived
  * A follow-up message can be sent confirming the item was returned

These <code class="expression">space.vars.automations</code> rely on **stage changes**, which is why creating a workflow is an essential step in managing operational processes.

***

## Workflow Capabilities by Role

{% columns %}
{% column %}

#### Admins

* Create and manage Workflow <code class="expression">space.vars.objects</code>
* Define stages and lifecycle structures
* Configure permissions and access controls
* Design operational processes used across the organization
  {% endcolumn %}

{% column %}

#### Technical Builders

* Integrate external systems that create or update workflow Records
* Trigger <code class="expression">space.vars.automations</code> when Records change stage
* Use APIs to manage workflow-enabled Objects programmatically
* Build scalable workflow pipelines that support operational <code class="expression">space.vars.automations</code>
  {% endcolumn %}
  {% endcolumns %}

***

## Tying It Back Into Your Industry

The **Lost Item Request Workflow** at <code class="expression">space.vars.Theme\_park\_name</code> is just one example of how organizations use workflows to manage operational processes. The same structure appears across many industries.

{% tabs %}
{% tab title="Insurance" %}
In insurance, workflows are frequently used to manage the lifecycle of a claim. When a policyholder reports an incident, the claim must move through several stages as it is reviewed and processed by different teams.

A typical claim workflow might look like:

Claim Submitted → Investigation → Documentation Review → Approved → Closed

Each stage represents a specific step in the claims process.

For example:

* **Claim Submitted:** A policyholder reports an incident, such as a car accident or property damage. A claim record is created in the system.
* **Investigation:** Claims adjusters review the incident, assess damages, and determine coverage eligibility.
* **Documentation Review:** Supporting materials such as photos, estimates, and statements are collected and verified.
* **Approved:** The insurer confirms the claim is valid and authorizes payment.
* **Closed:** Payment is issued and the claim is finalized.

As the claim moves through these stages, the system can trigger automated actions such as assigning adjusters, requesting documentation, notifying customers of updates, or initiating payment processing.

Just like the Lost Item Request workflow tracks the progress of a search at <code class="expression">space.vars.Theme\_park\_name</code>, a Claims Workflow tracks the progress of an insurance investigation from the moment it is reported until it is resolved.
{% endtab %}

{% tab title="Healthcare" %}
In healthcare, workflows are frequently used to manage the lifecycle of a patient referral. When a provider refers a patient to a specialist, the request must move through several stages as it is reviewed, verified, and scheduled by different team members.

A typical referral workflow might look like:

Referral Received → Insurance Verified → Appointment Scheduled → Visit Completed → Follow-Up Sent

Each stage represents a specific step in the referral process.

For example:

* **Referral Received:** A provider submits a referral for a patient to see a specialist. A referral record is created in the system.
* **Insurance Verified:** The administrative team confirms the patient's coverage and obtains any necessary authorizations.
* **Appointment Scheduled:** The specialist's office confirms availability and books the patient's appointment.
* **Visit Completed:** The patient attends the appointment and the specialist submits their notes back to the referring provider.
* **Follow-Up Sent:** The care team reviews the outcome and sends any follow-up instructions or next steps to the patient.

As the referral moves through these stages, the system can trigger automated actions such as notifying the patient of their appointment, alerting staff when authorization is still pending, or sending follow-up communications once the visit is complete.

Just like the Lost Item Request workflow tracks the progress of a search at <code class="expression">space.vars.Theme\_park\_name</code>, a Referral Workflow tracks the progress of a patient referral from the moment it is submitted until care is complete.
{% endtab %}

{% tab title="Financial Services" %}
In financial services, workflows are frequently used to manage the lifecycle of a loan application. When a customer applies for a loan, the request must move through several stages as it is reviewed, evaluated, and approved by different teams.

A typical loan workflow might look like:

Application Received → Document Review → Risk Evaluation → Approved → Account Opened

Each stage represents a specific step in the lending process.

For example:

* **Application Received:** A customer submits a loan application. A record is created in the system and assigned to a lending coordinator.
* **Document Review:** The team collects and verifies supporting materials such as income statements, tax returns, and identification.
* **Risk Evaluation:** Underwriters assess the applicant's credit history, debt-to-income ratio, and overall financial profile.
* **Approved:** The institution confirms the loan terms and the customer accepts the offer.
* **Account Opened:** Funds are disbursed and the loan account is activated.

As the application moves through these stages, the system can trigger automated actions such as requesting missing documents, notifying the applicant of their status, alerting compliance teams for review, or initiating fund disbursement once approval is confirmed.

Just like the Lost Item Request workflow tracks the progress of a search at <code class="expression">space.vars.Theme\_park\_name</code>, a Loan Application Workflow tracks the progress of a lending request from the moment it is submitted until funds are in the customer's hands.
{% endtab %}
{% endtabs %}

***

## What’s Next?

Now that your **Lost Item Requests** Workflow <code class="expression">space.vars.object</code> is created, you’re ready to begin adding real requests. In the next topic, [Modify Your Workflow](/docs/kizen-basics/kizen-in-action/move-through-your-workflow-or-kizen-basics.md) you’ll move the **Lost Item Request Record** for Sofia’s backpack through stages.&#x20;


---

# 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/create-your-first-workflow-or-kizen-in-action.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.