> For the complete documentation index, see [llms.txt](https://learn.withessential.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.withessential.com/field-operations/inspection-reports/require-a-service-completion-date-and-mark-a-service-not-applicable.md). # Require a service completion date, and mark a service N/A Service questions on a report (the Done / Not Done questions tied to a recurring service) can require the technician to settle the service's date before the asset counts as finished. This is how you build real service history for equipment you have no records for: the technician is standing in front of it, and that is the only moment anyone can find out when it was last serviced. ## Turning it on **Required** is a setting on the service question inside the report itself, so it is part of report setup rather than something you switch on from your own Settings. Report templates are built and edited by Essential — open the Essential Assistant and use the **Talk to a human** tab to have it turned on or off for one of your reports. New service questions are required as soon as they are added. An existing report is unchanged until a new version is published with it switched on. ## What the technician sees With **Required** on, the asset is not complete — no green check, it stays in the unanswered filter, and the report cannot be published — until the technician answers the question **and** the service's date is settled. The question always needs an answer: Done, Not Done, or N/A. The date counts as settled when any of these is true: * A completion is already on file for that asset and service — the date is inherited, so answering the question is all that's left. * The technician answers **Done** — that records a completion dated today. * The technician settles the question's date row. For a completion-based schedule on web or mobile, enter the **Last service or installation date**; the calculated **Next due** date appears underneath. For a fixed schedule, choose the due occurrence this work satisfies. * The technician answers **N/A** on the question itself. Choosing **Done** sets the last service date to today, replacing any historical date entered before marking the work done. **Next due** updates from the new date. If the work happened on a different day, choose **Edit** afterward to set the correct date; that override stays when you save or reopen the report. On fixed schedules, the separate **Due date** continues to identify the occurrence being satisfied. In practice the only extra work is **Not Done on equipment with no history**: there is no date on file and Not Done doesn't create one, so the technician either sets the date or marks the service N/A. That is the moment this setting exists for. ## Answering N/A Service questions offer three answers: **Done**, **Not Done**, and **N/A**. N/A means this service is not tracked for this piece of equipment at all — it was never on a schedule that applies here. Choosing N/A hides the date row, and on publish it **deletes that asset's completion history for that service**. With no completions left, the service stops producing a next due date for that asset and drops out of due tracking. That deletion cannot be undone, so use N/A only when the service genuinely does not apply to the equipment. If the service simply was not performed on this visit, answer **Not Done** instead — that keeps the history and lets you record when it actually was last done. ## Recording a date without marking the service Done The date row is available whatever the answer is. On a schedule based on the last completion, setting a date on a question answered **Not Done** records when the service was last performed, without claiming it was done on this visit. That is the normal way to backfill history for equipment you have just taken on. On web or mobile, choose **Add** or **Edit** beneath **Last service or installation date** and choose the date the work happened or the equipment was installed. Essential calculates and displays **Next due** using the recurring service schedule; you do not need to add the service interval yourself. On a fixed schedule, the row is labeled **Due date** and chooses the scheduled occurrence that completed work will satisfy; it does not rewrite the actual work date. Choosing a due occurrence while the answer is **Not Done** does not create historical work or advance the schedule. If you undo recorded work on a fixed schedule and publish the correction, Essential restores the prior schedule when that work still owns the change. Later office edits and other completed work are preserved. For older completions without enough saved schedule history, Essential asks the office to review the due date before removing the completion. > **Where to find it:** On an open inspection report, the service questions (Done / Not Done / N/A) and the date row beneath them. To have **Required** switched on for a report, use the Essential Assistant's Talk to a human tab. ## Estimated installation dates On web and mobile, a recent manufacture date or year can fill a missing **Last service or installation date** when the equipment has an applicable recurring schedule. The date is labeled **Estimated from manufacture date**. Existing service history and your manual entries take precedence. New equipment added while editing a published report can receive the same estimates. For **Done / Not Done** questions, Essential selects **Not Done** only when the estimated next due date is more than 35 days away. Service-linked **Pass / Fail** questions can receive the historical date, but you still answer the inspection yourself. **Next due** appears as a month and year with the time remaining, such as **Sep 2031 (in 5 years)**. For applicable extinguishers, a recorded hydrostatic test can supply the six-year maintenance baseline, labeled **Based on last hydrostatic test**. Six-year maintenance does not create a hydrostatic test date. Changing the manufacture or hydrostatic date updates untouched estimates. If you have edited a service date yourself, Essential keeps your date and offers **Update to** the revised date. Estimates stay anchored when you save or reopen the report; they do not move forward each day. ## Related guides * [What a service completion is and how it's recorded](/administration/how-recurring-service-automation-works-the-full-cycle/what-a-service-completion-is-and-how-its-recorded.md) * [What "Awaiting Service Completion" means and how it clears](/administration/how-recurring-service-automation-works-the-full-cycle/what-awaiting-service-completion-means-and-how-it-clears.md) * [How recurring service automation works (the full cycle)](/administration/how-recurring-service-automation-works-the-full-cycle.md) * [The field types you fill in on a report](/field-operations/inspection-reports/the-field-types-you-fill-in-on-a-report.md) * [Save a draft and publish an inspection report](/field-operations/inspection-reports/save-a-draft-and-publish-an-inspection-report.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://learn.withessential.com/field-operations/inspection-reports/require-a-service-completion-date-and-mark-a-service-not-applicable.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.