LearnSN Request access →

LearnSNSample › Lesson

Lesson

Start, stop, pause: the conditions that drive everything

Lesson 3 of 11 in Service Level Management — The clock on every ticket — definitions, schedules, and honest attainment.

Guide form: the mechanism as an ordered sequence, the field semantics as a table, the hard-won part as symptom / cause / fix, and the opinion as a flat rule. Nothing below is summarised or shortened for the sample.

A definition is mostly conditions. Each one is a stored condition string, evaluated against the task on every insert and update.

FieldWhat it doesTested against
start_conditionAttaches the clock. When it becomes true a task_sla row is created.Records that do not already have an active clock for this definition.
stop_conditionEnds the clock. Stage moves to completed.Records that do have an active clock for this definition.
pause_conditionSuspends the clock.Evaluated continuously while the clock runs.
cancel_conditionCancels the clock, when when_to_cancel is set to use it.Records with an active clock.
reset_conditionHandles the edge where a clock should start again on the same task.Records with an active clock, alongside reset_action.
The five conditions on contract_sla

What the engine does on a task update

  1. Find the active definitions whose collection matches this table.
  2. For each definition with no active clock on this record, test start_condition. If true, create a task_sla row and stamp its schedule, timezone and planned_end_time.
  3. For each definition with an active clock, test stop_condition. If true, stop the clock and move stage to completed.
  4. Test pause_condition against the running clocks and suspend or resume accordingly.
  5. Apply when_to_cancel and reset_action to whatever is left.
FieldOptionMeaning
when_to_resumePause conditions are not metThe default. The clock resumes the moment the pause condition stops matching.
when_to_resumeResume conditions are metA separate resume_condition must fire. This is how you build a pause that needs an explicit action rather than an incidental field change.
when_to_cancelStart condition no longer matches, a cancel condition matches, or neverThe choice decides what happens to a clock whose reason for existing went away.
Two settings decide how a pause and a cancel actually end
SymptomA P1 clock vanishes, or strands, when triage corrects the priority to 2.
CauseThe start condition can un-match. "Priority is 1" stops being true, and what happens next depends entirely on when_to_cancel.
FixSet when_to_cancel deliberately for every definition whose start condition can reverse. The default is not always what the business expects.
SymptomA clock never ends.
CauseThe stop condition is a subset of the start condition, or it is absent altogether.
FixWrite the stop condition against the ending state, not against the absence of the starting one. Then test it on a ticket that actually closes.
SymptomSaves on a high-volume table are measurably slower, and no business rule explains it.
CauseConditions are the performance surface of this module. Every active definition whose collection matches the table adds condition evaluation to every insert and update. adv_condition_type records how expensive that is: a plain field comparison is cheap, but "Has advanced with Journal" makes the engine read journal entries to decide, which adds queries on sys_journal_field to every save.
FixOn an instance doing tens of thousands of incident updates a day, a handful of journal-aware conditions is measurable in transaction time. It is invisible to every profiling tool that looks only at business rules, so go and read adv_condition_type on each active definition.
SymptomThe SLA module behaves in ways the documentation cannot explain.
CauseThe condition_class reference points at a script include implementing condition evaluation, and a previous partner replaced it. This is one of the few genuinely hostile customizations in this area.
FixCheck condition_class before you debug anything else.

Pause only for hold reasons genuinely outside the team's control, such as awaiting caller or awaiting vendor. Then report paused duration by hold reason as a first-class metric, so gaming is visible next to the attainment number rather than hidden inside it.

Why pausing on "state is On Hold" is contested

It is the vendor-obvious answer and it is also the single biggest incentive for metric gaming on the platform. A team under attainment pressure can stop the clock by parking the ticket.

The third tier

Every lesson can carry an expert note: what you only learn running the thing at scale. It is optional by design — absent is better than padded — so it is missing wherever we had nothing honest to add. This one has it.

Expert — what you only learn running it

Conditions are the performance surface of this module, not just its logic. Every active definition whose collection matches a table adds condition evaluation to every insert and update of that table, and adv_condition_type records how expensive that evaluation is: a plain field comparison is cheap, but "Has advanced with Journal" means the engine must read journal entries to decide, which turns an SLA condition into extra queries on sys_journal_field for every save of a high-volume table. On an instance doing tens of thousands of incident updates a day, a handful of journal-aware conditions is measurable in transaction time, and it is invisible in every profiling tool that looks only at business rules. The condition_class reference is the deeper hook — it points at a script include implementing the condition evaluation, and a previous partner having replaced it is one of the few genuinely hostile customizations in this area, because the SLA module then behaves in ways the documentation cannot explain. Check it before you debug anything else. On the design side, the argument senior architects have is about pause conditions on hold states: pausing on "state is On Hold" is the vendor-obvious answer and it is also the single biggest incentive for metric gaming on the platform, because a team under attainment pressure can stop the clock by parking the ticket. The defensible middle ground is to pause only for hold reasons genuinely outside the team's control — awaiting caller, awaiting vendor — and to report paused duration by hold reason as a first-class metric so the gaming, if it happens, is visible next to the attainment number rather than hidden inside it.

What a static page cannot show you. In the app this lesson sits inside Service Level Management next to an animated graph of the module's 10 tables, 1 debugging drill played on that graph, 4 labs and 3 build tasks you build for real on your own dev instance and have graded by read-only queries against what you actually built. None of that is on this page, and this page does not pretend otherwise.

608 more pages are behind the invite.

This sample is 4 pages — this one and 3 others — generated straight from the corpus behind the app: 31 modules, 335 lessons, 238 how-to guides and 39 architecture decision guides. The rest is behind an invite.

Access is invite-based and free, and requests are read by a human — expect your invite by email within a day or two.