> **Source:** https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation
> **Site:** Leegality Knowledge Base — https://knowledge.leegality.com
> **About:** Leegality is a document execution platform covering eSigning, stamps, NeSL, workflows, and REST API integration.
> **Navigation:** Every article on this site has a plain-text version at `<article-url>.txt` (this format). To get an index of all articles with their `.txt` links, read: https://knowledge.leegality.com/llms.txt
> **AI Guide:** For instructions on how to navigate this knowledge base as an AI agent, read: https://knowledge.leegality.com/ai-readable.txt

---
# Adding an Obligation

> When you add an obligation, you are recording a commitment that one of your contracts creates, so that the module can track it on your behalf. You give the comm

When you add an obligation, you are recording a commitment that one of your contracts creates, so that the module can track it on your behalf. You give the commitment a due date, say who is responsible for it, and decide whether it should raise a task and send reminders as that date approaches.

Most obligations are found for you by AI when a contract is executed. You add one yourself when the commitment is not covered by a template, or when you would rather not wait for the next extraction run.

You can only add an obligation to a contract that has already been executed, so a document at any earlier stage cannot be selected. You also need at least one obligation category, because every obligation belongs to one. See [Managing Obligation Categories](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories) if you have not set any up yet.

> **Tip — Adding the same obligation again and again?**
>
> If a commitment appears across many of your contracts, set up an [obligation template](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template) instead. The AI then finds it in every contract that matches, so you do not have to add it by hand each time.

## Opening the Add Obligation Form

<!-- ARCADE · P1 · Open the Add Obligation form
     Show: the sidebar Obligations entry, Manage, then the + Add Obligation button and the form opening.
-->

1. In the sidebar, click **Obligations**.
2. Click **Manage**. The full list of obligations opens.
3. Click **+ Add Obligation**. The form opens at **Obligation Details**.

You add an obligation in two steps. First you enter the obligation's own details. Then you set up the task and the notifications that go with it.

## Step 1: Obligation Details

1. Select the **Document Name**. This is the executed contract that the obligation belongs to, and it is required.
2. Enter an **Obligation Name**. This is required and can be up to 100 characters.
3. Add a **Description** of what the obligation requires. This is optional and can be up to 2,000 characters.
4. Add a **Source Clause**. This is the wording in the contract that creates the obligation, and it is optional. Click **Add from Document** to select the text, or open the PDF viewer. Obligations found by AI already include this.

5. Select a **Category**. This is required.
6. Set a **Priority**: **Critical**, **High**, **Medium**, or **Low**. This is optional.
7. Select the **Responsibility**, which is who the obligation belongs to. At least one is required, and you can select more than one:
    - **Us**: your own organisation.
    - **Counterparty**: the other party to the agreement.
    - **Third Party**: a party outside the agreement, such as a vendor or a regulator.
8. Set the **Assignee**. This is optional, and you can use either option or both:
    - **Assignee (by contract role)**: whoever holds a role on the contract, either **Business Negotiator**, **Legal Negotiator**, or **Initiator / Uploader**. See [Configure Collaborators](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow#configure-collaborators).
    - **Assignee (by user)**: a specific user in your organisation. The assignee receives the task assignments and reminders.
9. Turn on **Survives termination** if the obligation still applies after the agreement ends. This is optional.
10. Choose how the due date is set, either **One-time** or **Scheduled**. You have to choose one. Fill in that tab:

#### One-Time

Use one of these two options. You cannot use both, because an obligation takes its due date from a single source.

- **Link due date to reference variable**: the due date comes from a date field on the contract, such as its expiry date. Select a **Reference variable** from the dropdown, which lists date fields only. If there are none, click **Add new variable** to create one.
- **Next Due Date**: pick a fixed date from the calendar.

The due date cannot be in the past.

> **Caution — Important**
>
> If you link the due date to a reference variable and that variable's value changes later, for example because the contract was re-extracted, any task that has already been created stays on the original due date. The obligation is flagged with a conflict so that you can review it and update the task settings.
> 
> Do not assume that a changed contract date has been applied everywhere on its own.

#### Scheduled

1. Enter a **Start Date**. This is when the cycle begins.

> **Caution — Important**
>
> The first due date is not the start date. It falls one full interval after it. If you set a start date of 1 January and the obligation repeats every 3 months, the first due date is 1 April.

2. Set **Repeats**, using a number and a unit of days, weeks, months, or years.
3. Choose when it **Ends**:
    - A fixed number of occurrences, or an end date. The obligation stops once it reaches that point.
    - **Till Expiry**: the obligation keeps repeating with no fixed end. It stops only when someone marks it as expired.

11. Enter the **Resolution**, which describes what needs to be done to meet the obligation. This is optional.
12. Click **Next**. The **Tasks & Notifications** step opens.

## Step 2: Tasks & Notifications {#tasks--notifications}

Creating a task is optional. To track the obligation without one, click **Save**.

To create a task:

1. Turn on **Create task**.
2. In **Task creation date**, enter how many days before the due date the task should be created.
3. In **Turn around time (TAT)**, enter how many days the assignee then has to complete the task.

> **Info — Note**
>
> These two settings do different things. The task creation date decides when the task appears. The TAT decides how long there is to finish it, counting from when it appears. A task that is not completed within the TAT window is breached.
> 
>     Because the TAT starts when the task is created, it cannot extend past the due date. If it does, either reduce the TAT or create the task earlier.

4. Turn on **Send TAT breach email notification** to alert recipients when a task breaches its TAT. This is optional.
5. Turn on **Repeat reminders** to send reminders after the first one, which always goes out. This is optional. Then set:
    - **Notify on**: when reminders are sent, either on task creation, on TAT Breach, or both.
    - **Repeats every**: how often the reminder repeats, in days.
    - **Ends after**: how many reminders to send before stopping. Select 1, 2, 3, 5, or 10.
6. Add **Additional notification recipient(s)** by searching for a user and selecting them. This is optional.
7. Click **Save**.

The obligation is saved. It appears in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations) with the status **Active** and the source **Manual**. If you set up a task, it is created on the date you chose, not immediately.

## Rules to Know

- If you turn on **Create task**, the obligation needs a due date source. Without either a fixed due date or a linked reference variable, it will not save.
- The task creation date must be in the future. If the due date is close, there may not be room to create the task before it.
- On a scheduled obligation, the task creation window cannot overlap the next occurrence. The number of days before the due date cannot be more than the gap between two occurrences, so one cycle's task never collides with the next.

## Related Pages

- [What is an Obligation?](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview)
- [Managing Obligations](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations)
- [Obligations Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard)
- [Creating an Obligation Template](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template)

> **Tip — Reference**
>
> See [Tasks](https://knowledge.leegality.com/deal-collaboration/tasks) for how the task is listed, tracked, and resolved.

<!-- ==================== POC REVIEW NOTES (not rendered) ====================
TONE PASS (2026-09-03). Language only. Every step, field, limit, rule and
table row is unchanged — the sequence and the facts are exactly as verified.

What changed and why:
- Em dashes removed almost entirely. They were the main reason the writing
  read as machine-generated: this section ran at 11.1 per 100 lines against
  1.5 across the repo's published DC pages.
- "(Optional)" italic markers replaced with a plain sentence, "This is
  optional." Conga states such things in a short following sentence rather
  than with inline typographic markers, and it reads more naturally aloud.
- Field explanations moved out of dashes into their own sentences. For example
  "Select the Document Name — the executed contract this obligation belongs
  to" became two sentences.
- Admonition titles made plain, matching the repo: ":::caution[The first due
  date is not the start date]" is now ":::caution[Important]", and
  ":::info[These two settings do different things]" is now ":::info[Note]".
  The point each one made is now the first line of its body.
- Results stated after actions, which is Conga's clearest habit. Step 13 now
  says the next step opens, and the save now states where the obligation
  appears and with what status.
- Editorial phrasing removed: "and you are done", "at a glance", "worth
  pausing on", "Choose one source" kept but plainer, "will stop the obligation
  from saving" became "it will not save".
- Field Reference em dashes for empty cells replaced with blank cells.
- Spelling changed to "organisation" to match the repo's existing usage.

KEPT deliberately, against Conga's style: bold UI labels and titled
admonitions. Conga uses plain text for UI elements and a bare "Note:" prefix,
but this repo bolds UI labels throughout and uses ":::info[Note]" blocks.

Anchor preserved: "{#tasks--notifications}", linked from the overview page and
from create-obligation-template.

--- CONTENT QUESTIONS (unchanged by the tone pass) ---

1. REFERENCE VARIABLE SYNC — NEEDS A DECISION. The UI helper text says the
   due date is "kept in sync automatically — if the variable changes, the due
   date updates too." The backend says terminal_due_date is "snapshotted at
   create time; variable drift surfaces as a conflict rather than
   auto-updating this field", and the conflict message tells the user
   "Existing tasks are still tied to the old due date."
   Both can be true if the due date follows the variable while already-created
   TASKS do not. This page therefore states neither claim, and the overview
   page describes the conflict behaviour. Please confirm with engineering
   which is accurate — it changes what we tell customers about whether action
   is needed when a contract date changes.

2. "ENDS" OPTION LABELS. The two options are CUSTOM and TILL_EXPIRY
   internally. "Till Expiry" is confirmed; the label for the fixed-bound
   option is not (an earlier draft called it "After"). Step 11's Scheduled tab
   describes it rather than naming it. Confirm from the UI.

3. TILL EXPIRY WORDING. The UI helper says "keeps repeating indefinitely — no
   fixed end. It only stops when you manually mark it as expired," which is
   what this page follows. A backend comment instead describes it as running
   "until the contract expires". Confirm which is right — they differ for a
   contract that expires while the obligation is still repeating.

4. TAT LIMITS. A string "TAT value can be between 1 - 20 day(s)" exists in
   translations but sits among document-TAT strings, so it may not apply to
   obligation tasks. The API only enforces a minimum of 0. Confirm whether
   obligation TAT has an upper bound before documenting one.

5. STEP-1 GROUPING. The frontend has DETAILS and CLASSIFICATION strings. An
   earlier version used them as sub-headings; the steps are now one
   continuous list. If the form visually separates those groups on screen, the
   sub-headings should come back as labels that do not restart the numbering.

6. RESPONSIBILITY "ANY". The frontend has an "Any" option with helper text
   "Choose Any to keep it open-ended", and the API's responsibility choices do
   include ANY — but a code comment says ANY is a seed-only value for default
   templates and is "not accepted from API payloads" (which the code
   contradicts). Omitted from step 8 pending confirmation of whether Any is
   offered on an obligation or only on a template.

7. STEP 13 RESULT. This page now states that clicking Next opens the
   "Tasks & Notifications" step. That follows from the two-step form, but the
   on-screen transition was not observed. Confirm when recording the Arcade.
========================================================================== -->