What it does

An agreement is a recurring service contract that generates work orders — and optionally invoices — on a schedule, with predefined incidents, products, services and tasks. It's how planned maintenance, statutory inspections and contracted visits get into the system without anyone typing them.

Key facts

• The structure is layered: Agreement → Agreement Booking Setup (the recurrence) → Agreement Booking Incident (the work) → Agreement Booking Date (the generated instance) → Work Order. Each level has its own records and its own failure modes.
• An agreement operates at a single location, meaning one service account. Multiple sites means multiple agreements.
• The agreement carries service account, billing account, start and end dates, price list, system status, and a Record Generation Time that controls what time of day the generation job runs. Set it outside business hours.
• Agreement Booking Setup holds the recurrence pattern and range (no end date, end by date, or after N occurrences), plus custom one-off dates.
• Auto Generate Work Order and Generate Work Orders Day in Advance control creation. The advance window defaults to 7 days.
• Auto Generate Booking will book the work order to a preferred resource automatically. Pre- and post-booking flexibility (days either side) and a time window define the acceptable slot.
• Activating the agreement generates Booking Dates with status Active. When the advance window is reached, the work order is created and the Booking Date flips to Processed.
• Agreement processes run under the owner's permissions. Set a system user or team as owner before creating the agreement, or generation fails quietly for records the owner can't see.
• Keep generated work order child records at or below 500 to avoid timeouts.
• Work order invoices fire at Posted. Agreement invoices are a separate setup. Running both double-bills, so if you use agreement invoices you need to suppress work order invoicing — deactivate them, or use entitlements to zero the work order subtotal.
• Multiple incidents in one booking setup produce a single work order; multiple booking setups produce multiple work orders. That choice decides whether one technician does everything in one visit or you get separate jobs per asset.

When to use / skip

Use agreements where the recurrence is genuinely contractual and stable: annual gas safety checks, quarterly PPM rounds, monthly lift inspections. That's what they're built for and they do it well.

Be much more careful where the client's "recurring" work is actually a rolling plan that changes constantly. Agreements are not a lightweight scheduling tool — an activated agreement with a year of booking dates is awkward to restructure, and clients who treat it as a to-do list end up with hundreds of orphaned dates.

Also skip them where the recurrence is per-asset and the asset population churns. Adding and removing assets from live agreements every month is more work than generating jobs from a flow. If the client's maintenance plan lives in a spreadsheet that changes weekly, be honest that agreements will fight that.

Configuration decisions

• One agreement per site, per contract, or per asset group — this determines how many records the client will be maintaining forever.
• Multiple incidents in one booking setup versus multiple booking setups: one visit and less travel, or separate work orders with clean per-asset traceability and separate billing.
• Auto Generate Work Order versus manual generation, and how many days in advance. Too short and dispatchers have no planning runway; too long and cancellations create noise.
• Whether Auto Generate Booking is used, or whether Resource Scheduling Optimization takes the generated work orders and schedules them — and if RSO, whether those work orders are actually in scope.
• Invoicing model: work order invoices, agreement invoices, or both with one suppressed. Decide before activation.
• Whether incident items are snapshotted into the agreement (Copy Incident Items to Agreement = Yes) or resolved live from the incident type.
• Who owns agreement records, given that generation runs with the owner's privileges.

Gotchas

• Ownership is the classic silent failure. An agreement owned by a departed user, or by someone with narrow business unit access, simply stops producing work orders. No error surfaces on the agreement.
• Double invoicing from having both agreement invoices and work order invoicing live is the expensive one. It reaches the customer before anyone notices.
• Changing the recurrence on an active agreement does not retrospectively fix already-generated Booking Dates. You clean those up by hand.
• Record Generation Time left at a default can drop hundreds of work orders into the middle of the working day, which looks like an outage to dispatchers.
• Copy Incident Items to Agreement = Yes freezes the work content at activation. Update the incident type two years later and existing agreements keep the old procedure.
• Price list on the agreement is what generated work orders inherit. If a contracted rate changes, updating the price list doesn't reprice work orders already generated.
• Agreements with many incidents and many products routinely trip the child record limit and generation times out partway, leaving half-built work orders.

Consultant notes

• Model one real contract end to end during the build — activate it, watch the booking dates appear, let a work order generate — before designing the other forty. The structure only makes sense once you've seen it run.
• Set agreement ownership to a team, not an individual, and say so explicitly at handover. It's the single change that prevents the most common post-go-live failure.
• Demo the invoicing choice to finance early. Agreement invoicing versus work order invoicing is their decision, not the client's IT team's, and it's painful to reverse.
• Before go-live, check Record Generation Time, the advance window, and that generated work orders land in RSO scope if RSO is doing the scheduling.
• Tell the client that agreements are contract data with a lifecycle — someone must end them, renew them and reprice them. Left alone, they generate work orders against expired contracts indefinitely.

---

Worth another look if the generation limits or the agreement invoicing behaviour change in a future wave.