# Commit

Commit is the workflow that moves data changes from a proposed state into the live ServiceNow record. You or a reviewer **commit** a change to accept it, or **reject** it (with a required reason) to send it back.

> **Note on naming:** If you see the word "Publish" or "Publishing" anywhere in the interface or in a notification, it refers to the same Commit workflow described here. The terminology will be aligned to "Commit" across every surface in an upcoming release.

## Where You Commit

Commit lives in the **Explorer Panel** — the model explorer view in a board's preview. You open the Explorer, select one or more rows with pending data, and act on them from the buttons at the bottom of the grid.

<figure><img src="/files/jB1HgqgvNudTad1ykZ6D" alt=""><figcaption></figcaption></figure>

## Row Statuses

Every row has a status that reflects where it is in the commit flow:

| Status            | What It Means                                                 |
| ----------------- | ------------------------------------------------------------- |
| **New**           | The row was added but has not been committed yet              |
| **Committed**     | The change is live in ServiceNow                              |
| **Rejected**      | The change was rejected and needs to be reworked              |
| **Scheduled**     | Queued for commit                                             |
| **To be deleted** | Marked for deletion pending commit                            |
| **Deleted**       | The delete has been committed                                 |
| **Error**         | The commit failed — see the notification for the error detail |

## Committing Rows

1. Open the **Model Explorer** tab in board preview.
2. Use the grid checkboxes to select one or more rows.
3. Click **Commit** (green, checkmark icon) at the bottom of the grid.
4. A notification appears to tell you the commit is in progress.
5. A success or partial-success notification reports the outcome; the grid refreshes.

If the commit partially fails, the notification lists the specific errors so you know which rows to retry.

## Rejecting Rows

Rejecting lets a reviewer send a proposed change back with a reason.

1. In the same grid, select the row(s) you want to reject.
2. Click **Reject** (red, cancel icon).
3. A dialog opens titled **Reject** with:
   * For a single row: *"Please specify why you are rejecting this item."*
   * For multiple rows: *"Multiple items selected for rejection. Please provide a reason."*
4. Fill in the required **Comment** field. The comment must be non-empty and has a maximum length.
5. Click **Confirm**.

Rejection sends the rows back to **Rejected** status and a notification reports the result.

## Roles & Gating

Commit and Reject availability depends on:

* **Whether the selected rows have committable data.** The buttons are disabled when nothing actionable is selected.
* **Your board/ServiceNow role.** Only users with commit/reject authority see the relevant button as enabled.
* **The status of the rows.** Already-committed rows can't be re-committed; already-deleted rows can't be rejected.

## Notifications

Commit and Reject both produce in-app toast notifications:

* **Commit** — an in-progress toast while the request runs, then a success or failure toast with the result
* **Reject** — an in-progress toast, then a success or failure toast

On partial failures, the notification includes the per-row error list so you can see exactly what went wrong. See [Notifications](/models/work-in-the-app/editor/notifications.md).

## Limits & Gotchas

* **Rejection requires a comment.** You can't reject without one.
* **Comments have a maximum length.** The dialog shows the limit when you hit it.
* **The grid refreshes after a commit or reject.** Cached node data is cleared so everything stays in sync.
* **Commit writes directly to ServiceNow.** There's no staging server — the target system sees the change as soon as Commit succeeds.
* **Only committed elements can be dropped on certain visualizations** (like [Context Map](/models/work-in-the-app/editor/visualizations/context-map.md)). Plan your commit sequence before assembling those visualizations.

## Related

* [Data Panel](/models/work-in-the-app/editor/data-inspector.md) — inspect and edit the data before you commit
* [Notifications](/models/work-in-the-app/editor/notifications.md) — where commit status surfaces
* [Versioning](/models/work-in-the-app/editor/versioning.md) — capture a version alongside a commit milestone
* [Comments](/models/work-in-the-app/editor/comments.md) — view conversation threads on committed elements


---

# 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://docs.ins-pi.com/models/work-in-the-app/editor/commit.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.