# Build a to-do application

In this tutorial, we will build a release checklist application with Pilot. It will allow you to organize a list of tasks and track their completion.

Pilot will help you build the release checklist, inspect its proposed Ontology, and test the generated application. The tutorial creates a new object type and actions, so use a project and Ontology where you can create resources.

The generated to-do application lets you add tasks, mark them complete or incomplete, filter the list, and delete tasks. Follow the application walkthrough first, or go to [reuse an existing task model](#reuse-an-existing-task-model) or [build the checklist as a widget](#build-the-checklist-as-a-widget) if you would like to jump to specific sections.

Generated layouts and names can vary. Compare the controls and results with the screenshots as you proceed. Orange outlines identify the controls or status indicators used in the adjacent steps.

## Create the application

Open Pilot and configure the welcome screen:

1. Set **Type** to **OSDK application**.
2. Set **Theme** to **Blueprint components**.
3. Select your **Save location** and **Ontology**.
4. Enter the following prompt in the prompt box:

```text
Build a todo application called Release checklist.

Create a new Release Checklist Task object type with an ID, title, and completed
status, plus actions to add a task, mark it complete or incomplete, and delete it.

Show a clear list with All, Active, and Completed filters and a remaining-task
count.

Use Blueprint components and synthetic sample tasks: Review the checklist,
Prepare the demo, and Confirm the release.

Do not modify any existing Ontology definitions.
```

The completed form should resemble the following. Use your own project and Ontology; **Pilot tutorial** and **Example Ontology** are example labels.

![The completed welcome form shows the release checklist prompt, OSDK application, Blueprint components, save location, and Ontology permissions.](../../../assets/5ce6a728c16d19f5ea80b024afe32643da10dc9d6daefcdecb5da285a84024a6.webp)

Before creating the application, allow Pilot to propose the new entities:

1. Select **Modify Ontology permissions**, beneath **Ontology**.
2. Enable **Allow Pilot to create new object types** and **Allow Pilot to create new action types**.
3. Leave both **Default edit permissions** controls set to **Do not allow modifications**, then select **Save**.

![The permissions dialog shows both creation switches enabled and modifications to existing definitions prohibited.](../../../assets/8d1a048d12b6c93eca810ebc08e4d00447b8fff54b0ed0fcbc7027a8a7670595.webp)

Back on the welcome screen, confirm that it says **Pilot can create new entities but not modify existing ones**. Select **Create application** and wait for container setup and generation to finish.

## Inspect the proposed data model

In the workspace, select **Ontology** above the application preview. This example needs:

* A `Release Checklist Task` object type with `ID`, `Title`, and `Completed` properties
* An action to add a task
* An action to set a task's completion status
* An action to delete a task

![The Ontology graph shows the proposed task object type and its three actions.](../../../assets/296d58144777a6365af27a9acd70875a9c0086bf51a8cb5a8312660ef74758f1.webp)

Check that the entities are marked **Proposed by Pilot**. They still need implementation in Foundry before the application can use them with production data.

Select the task object type to open its data preview. Confirm that the three requested sample tasks are present. If Pilot reused existing entities or generated a different model, describe the discrepancy in the chat and inspect the result again before deployment.

## Test with seed data

Select **Preview** and confirm that **Notional data** is selected. The screenshot shows where to find the data-source control, task input, and filters.

![The Preview tab shows Notional data selected, the task input, and the All, Active, and Completed filters.](../../../assets/e7f279219504d4b59bc62a883b0f4e4ece2d81ca268a08e6965501abfaee401c.webp)

Test the generated controls:

1. Enter `Verify the published checklist` and select **Add task**. Confirm that the task appears and the remaining count increases by one.
2. Mark the task complete. Confirm that its checkbox is selected and the remaining count decreases by one.
3. Select **Completed**. Confirm that the completed task appears.
4. Select **Active**. Confirm that the completed task is absent.
5. Return to **All** and reload the preview. Confirm that the task and its completed state remain.
6. Mark the task incomplete. Confirm that the remaining count increases.
7. Delete this test task. Confirm that it disappears and the original sample tasks remain.

If a control fails, describe the actual behavior and expected result to Pilot, then repeat the check after the fix. These checks validate local preview behavior; production permissions and the proposed Ontology definitions still need validation.

## Implement the Ontology on a branch

Select **Deploy** in the upper-right corner of Pilot. This opens the deployment checklist on the left of the preview. The example below shows a configured application; your checklist will reflect your progress.

![The Editor and Deploy control is outlined above the deployment checklist and application preview.](../../../assets/2ba22e87187f6f157d48266b67f6c646591cfe182f4a640c44100b084723ee89.webp)

Under **Implement Ontology entities**, new definitions can appear as **Not found** on **Main**. Create a deployment branch for them:

1. Select **Create branch**. Pilot may open the **Create deployment branch** dialog when you first enter **Deploy**.
2. Enter a branch name such as `Release checklist tutorial`.
3. Check the **Location** and **Application entities**. This example proposes one object type and three action types.
4. When the form is ready, select **Create branch**.

![The Create deployment branch dialog shows the branch name, save location, one object type, and three action types.](../../../assets/4d2c82b68910729b3ed907733f535da1444e17447c43de764fa1f78159a2641f.webp)

Wait for implementation and object indexing. While indexing is in progress, actions can fail and data can be missing. If branch creation is unavailable, inspect the explanation; Global Branching must be enabled.

After implementation, check the selected **Branch** on the left and **Production data on branch** above the preview.

![The deployment view shows the tutorial branch, entities added to that branch, the Production data on branch indicator, and View branch.](../../../assets/83801c3155ee3c27fc8a002cf449344f2df5b19fb9c09e2c6dd35ad4cb77ec66.webp)

The branch preview uses records on the selected Foundry branch. The local seed tasks are separate, so the new task object type can initially have no records.

To validate the application, add a release task such as `Validate the deployment branch`, repeat the completion, filter, reload, and delete checks, and remove the test task when finished. Then select **View branch** to open Global Branching.

## Review and merge the Ontology proposal

In Global Branching:

1. Confirm that the branch contains the task object type and three actions.
2. Select **Create proposal** in the upper-right corner.
3. Enter a **Proposal name** and **Proposal description**, then select **Create**.

![The Create proposal dialog shows a name, description, and Create button.](../../../assets/a85cbfad711deb38fc2ed9f8f2b6699860367ee39fefd9a74b84aafa4865c893.webp)

Wait for the task object type to finish indexing, then review the proposal before merging:

1. Open **Changes** and confirm that the proposal creates the intended task object type and actions without modifying unrelated definitions.
2. Return to **Overview** to inspect the resource checks and required approvals. The example below shows four resources with passed checks and automatic approvals; your policies can differ.
3. Select **Merge proposal**, review the confirmation, and confirm **Merge proposal**. Wait for the proposal to show **Merged**.

![The Ontology proposal lists four resources with their approval and check indicators.](../../../assets/3a4772a8559cb7e865feb6d7b743d22f8ed06b957cbd59de6f9fd3f3538ecec6.webp)

Return to Pilot and select **Switch to Main**. Confirm that **Implement Ontology entities** reports **All entities up to date on Main**.

Review the generated actions' submission criteria before sharing the application. The default criteria allow only the user who created the action with Pilot to submit it. Configure the intended access in Ontology Manager.

## Configure the application and run checks

In the deployment checklist, open **Configure application and subdomain** and select **Configure application**.

1. Enter a **Developer Console application name**, such as `Release checklist tutorial`.
2. Select the **Organization**. The **Subdomain** field appears after this selection.
3. Enter an available subdomain. Wait for the availability check, then select **Create application**.

![The Configure application dialog shows the application name, organization, subdomain field, and Create application button.](../../../assets/ad0c8ac99d8a5c11bc4cbe36524d5929a5380de302011fda9e16a4cda23d6c9c.webp)

Confirm that the application card appears and reports **Application scope up to date**. If it displays **Domain pending approval**, contact your enrollment administrator to approve the request before hosting the website. See [Approve the subdomain request](../deploy-an-application/index.md#approve-the-subdomain-request).

Next, open **Pass all CI checks**.

1. Select **Generate deployment files to enable checks** when prompted, or **Update files** if the deployment files are outdated.
2. Wait for **SUCCEEDED** on the commit you intend to release.
3. If a check fails, open its build output, ask Pilot to fix the reported problem, and wait for checks on the updated commit to pass.

![The deployment checklist shows successful CI and the Tag and release button while domain approval remains pending.](../../../assets/f909bfc82670abc219049736ecef6ffe7007402c8ccdb1acc40ec3819a7e72e2.webp)

## Release and verify the hosted application

After successful checks, select **Tag and release** at the bottom of the deployment checklist:

1. Review the selected branch or commit and the latest released tag.
2. Choose **Patch**, **Minor**, **Major**, or **Custom**.
3. Check **Releasing** at the bottom of the dialog, then confirm **Tag and release**. The example selects patch version `0.0.2`; your version numbers can differ.

![The Tag and release dialog shows the selected branch, version options, resulting tag, and confirmation button.](../../../assets/7837325e734d66151923d008acaccda8144af2d32773d2ee7e543db3037d7997.webp)

Wait for the release build to succeed. Creating a tag does not approve the domain or confirm that the website is available.

Complete domain approval and follow the [application release steps](../deploy-an-application/index.md#tag-and-release). Open the hosted application after deployment succeeds and repeat the seven task checks against a synthetic test task. Verify the data source and your permissions before executing actions against real records.

## Reuse an existing task model

To build against existing definitions, open the Pilot welcome screen:

1. Set **Type** to **OSDK application** and choose your theme, save location, and Ontology.
2. Select **Add context > Add object types**, search for your task object type, and open its details. Choose **Select**, then **Confirm selection**.
3. Select **Add context > Add action types**. Filter by the affected task object type, select its add, completion, and delete actions, then choose **Confirm selection**.
4. In **Modify Ontology permissions**, keep creation and modification prohibited.
5. Describe the checklist interactions and explicitly ask Pilot to use only the selected existing definitions.

Before selecting **Create application**, check the four attachment tags beneath the prompt and the message **Pilot cannot make changes to the Ontology**.

![The welcome form shows an existing task object type and three action types attached beneath the prompt, with Ontology changes prohibited.](../../../assets/6622005c45f8923cb094d2f19aefc14365633668d2d4dd8e295d954ea1b1b6b7.webp)

After generation, inspect **Ontology**. This example should show **Existing 4** and **Proposed 0**, with **Do not allow modifications** on the object type and all three actions.

Repeat the seed-data checks. Then select **Production data**, wait for the preview to reload, and test the deployed actions using a synthetic task. Verify completion, filters, and persistence after reloading, then delete the test task. The production list is separate from the seed records.

Select **Deploy**. If the existing definitions are unchanged, confirm **All entities up to date on Main**. If **Create deployment branch** opens even though those definitions are up to date, select **Cancel**.

![The deployment view confirms that the existing task model is up to date on Main and shows the production checklist.](../../../assets/b6757243902dfcbab356383b3643bad2ababc634d52d6f667a6bbb6398424fa0.webp)

Continue with application configuration, CI, and release as described above.

## Build the checklist as a widget

To reuse the task model in Workshop:

1. Choose **Custom widget set** on the Pilot welcome screen.
2. Attach the same task object type and three actions through **Add context**.
3. Keep Ontology creation and modification prohibited.
4. Enter this prompt:

```text
Build a custom Workshop widget set called Shared workshop release checklist using
only the selected existing Release Checklist Task object type and the selected
Add Task, Mark Task Complete or Incomplete, and Delete Task actions.

Do not create new Ontology entities or modify any existing definitions.

Include a task input, completion checkboxes, per-task delete controls,
All/Active/Completed filters, and a remaining-task count.

Use Blueprint components and synthetic seed tasks Review the checklist,
Prepare the demo, and Confirm the release for the preview.
```

Compare the selected type and attachments with the following form, then select **Create widget set**.

![The completed widget form shows Custom widget set selected, the prompt and four existing-entity attachments, and prohibited Ontology changes.](../../../assets/7641f8c31564da29325822396e8dab3760ce68569bbb1130fbc0470dfee055ab.webp)

After generation, select the widget in **Preview** and confirm that **Notional data** is selected.

![The checklist widget preview shows three sample tasks, completion controls, filters, and a remaining-task count.](../../../assets/5bb020881922d83fbd09cedee56c10f7cd5281dac7b74706c9c2005d0cb93513.webp)

Repeat the seven interaction checks inside the widget sandbox. Also test submitting a task with `Enter`. If form submission is blocked, ask Pilot to use explicit button and keyboard handlers, then retest both input methods.

Confirm that sample tasks are registered as seed data rather than created automatically by submitting actions when the widget opens. Switch to **Production data** and test a synthetic task separately. Delete it after checking completion, filters, and persistence.

Select **Deploy**. If the existing definitions are unchanged, confirm **All entities up to date on Main**. Cancel an automatically opened deployment-branch dialog when no Ontology changes are required.

Under **Generate SDK**, select **Update SDK** if needed. Wait for **Widget SDK generated**, **Widget SDK installed**, and **On latest**. Use **Install** or **Upgrade to latest** if prompted.

![The widget deployment checklist shows the generated SDK installed and on the latest version.](../../../assets/af150f71c47a7371c6d6e471b1a3603e2edc1ead8dbdf7b7af74ab89dab7bd2f.webp)

Wait for widget CI to succeed, then select **Tag and release**. Confirm the release in the dialog and wait for the new tag to appear as the **Deployed version**. Continue with [widget deployment](../deploy-a-widget/index.md) if any checklist step is incomplete.

## Embed and test the released widget

Create a Workshop module in your project. See [Getting started with Workshop](../../workshop/getting-started/index.md#part-i-initial-setup) if this is your first module.

In the Workshop editor, select **Add widget**. In the widget picker, choose **Foundry & custom apps**, then **Custom widget**.

![The Workshop widget picker shows the Foundry and custom apps category above the widget list.](../../../assets/cd4bc70b00167d3e724a324996fefe9daca7ce3572e09609b72fd05191d9119c.webp)

Configure the widget in the right-hand panel:

1. Under **Widget setup**, choose **Select**, find your published widget set, and confirm the selection.
2. Choose the checklist under **Widget**.
3. Select its published **Version**. This example uses `0.0.3`.

![The Workshop Widget setup panel shows the selected checklist widget and published version.](../../../assets/24522ff741d061832b50ac4baddad1358be3eee116e1aa0ee87f0bcd216132dc.webp)

Next, check the layout:

1. Open **Display** and set **Row height** to **Flex** for this example. The generated widget fills its container; **Auto (max)** gave it zero height.
2. Arrange the surrounding sections. This example uses one section with **Column width** set to **Flex**.
3. Confirm that the checklist and its controls are visible. See [Auto sizing](../../custom-widgets/auto-sizing/index.md) if your widget uses a different layout.

![The Workshop editor shows the checklist widget and its Flex row-height setting in the Display panel.](../../../assets/8a5d9cb1f5ad14d950b68cad971cec2ad2e9df0f655905b1da8f0f706f682649.webp)

Select **Save and publish**, then **View**. If widget **Dev mode** is active, select **Pause** before testing the release, or **Stop** to end development mode. Selecting a published version alone does not disable your personal development override.

Repeat the seven task checks in the published Workshop module, including a full-page reload. Delete the synthetic task when finished. This example defines no parameters or events; if you add them, configure and test their Workshop bindings separately.

## Create a new task model for a widget

To build the widget with new definitions, choose **Custom widget set** on the welcome screen. Enable creation of object and action types in **Modify Ontology permissions**, as shown in the [application setup](#create-the-application), and leave modifications to existing definitions prohibited.

Enter this prompt, then select **Create widget set**.

```text
Build a custom Workshop widget set called Workshop release checklist.

Create a new Widget Checklist Task object type with an ID, title, and completed
status, plus actions to add a task, mark it complete or incomplete, and delete it.

Show a clear task list with All, Active, and Completed filters and a remaining-task
count.

Use Blueprint components and synthetic sample tasks: Review the checklist,
Prepare the demo, and Confirm the release.

Do not modify any existing Ontology definitions.
```

Inspect **Ontology** after generation. The expected result is four proposed entities: one task object type and three actions. If Pilot reused existing definitions, ask it to create distinct new API names and update the widget, then inspect the graph again.

Repeat the seed-data checks, including task submission with `Enter`. Follow the [Ontology deployment steps](#implement-the-ontology-on-a-branch), using **Branched data** for the widget's branch preview. Test and delete a synthetic task, review and merge the Ontology proposal, then return to **Main**.

After merging, update the SDK to include the new definitions. Confirm that the installed SDK is **On latest** and CI reports **SUCCEEDED** before selecting **Tag and release**.

![The new-entity widget deployment shows its task model on Main, the updated SDK, and successful CI checks.](../../../assets/4df12a5ac457ac0f83528ba03a25bea62339f9dd6694c32398184a6898630c48.webp)

If the preview times out or CI cannot find the new entities, see [Custom widget preview does not load](../troubleshooting/index.md#custom-widget-preview-does-not-load) and [Generate and install the SDK](../deploy-a-widget/index.md#generate-and-install-the-sdk).

### Configure a heading in Workshop

The new-entity widget generated for this example includes a string parameter named **Heading**. Your generated widget may expose different parameters; inspect its configuration first.

In the Workshop module, select the released widget:

1. Under **Widget setup > Parameters > Heading**, choose **Select string variable**.
2. Choose **New string variable > Static**, then open the created variable.
3. Set **Default value** to `Workshop release tasks` and name the variable `Checklist heading`.
4. Confirm that the widget displays the configured heading.

![The Workshop editor shows Heading bound to Checklist heading and the resulting Workshop release tasks title.](../../../assets/d0517741530ab298b54b6aa5ecf0ad1f8fee02a822614680f66907e8b027f805.webp)

Set the widget and section dimensions as described above. Select **Save and publish**, then **View**, and pause **Dev mode** if it is active.

Repeat all seven task checks. Confirm that both the heading and task completion persist after a full-page reload, then delete the synthetic task. This widget defines no events; event bindings require separate configuration and testing.