A matter plan that nobody follows is just a to-do list with extra steps

Almost always one of three causes. The due dates are not realistic for how those cases actually run, so people learn to ignore them and then ignore all of them. The tasks are assigned to named users rather than matter roles, so staffing changes orphan them. Or the plan was copied from a template and describes a process the team does not follow. The fix starts by looking at which tasks get closed without being done — that pattern tells you precisely which parts of the plan are fiction.

A matter plan is Litify's own structure: it generates a set of stages and tasks when a matter opens, based on the Case Type, and assigns them by role. It is configuration inside the package, visible to your admin, and the vendor upgrades it. Salesforce Flow handles everything the plan cannot express on its own — a due date that depends on jurisdiction, escalation when a task sits too long, conditional logic based on case facts. Good Litify automation uses the plan for the predictable skeleton and Flow for the judgement, rather than pushing everything into one of them.

Yes, and it is a common starting point. The cause is usually order of execution: several Flows, validation rules and possibly Apex triggers added over years by different people, each sensible alone, interacting in a sequence nobody has mapped. We inventory everything with ownership and last-modified dates, then trace every path a record can take on create and update in firing order. That exercise nearly always surfaces automation nobody knew was running, and it is what makes the edge cases explainable again.

That is an explicit design goal. Tunable values — deadline intervals, escalation thresholds, jurisdiction rules — live in custom metadata records rather than hard-coded in formulas, so your operations lead can change a threshold without a developer or a deployment. We build to a documented convention: one record-triggered Flow per object per timing, sub-flows for reusable logic, fault paths on everything, clear naming. Documentation is handed to your admin as part of the work, not offered as an extra.

Not if it is staged properly, which is why we never rewrite plans under active cases without a migration path. We work out which matters are on which plan version, decide with you whether in-flight matters move or finish on the old model, and roll out by practice area or case type rather than all at once. Live deadlines are the thing we are most careful about — losing one is a different category of problem from losing a report.

The rules go into custom metadata, one record per jurisdiction and case type, with the calculation basis, business-day handling and warning intervals as fields. Flow reads the rule rather than containing it. That matters for two reasons: the rules can be updated by the firm when a court changes its practice, without a code deployment; and the rule set has a named owner and an audit trail, rather than living in one senior paralegal's head where it does not survive their holiday.

No, and the distinction matters. This is deterministic automation — given these conditions, this task is created, this date is calculated, this person is notified. It does the same thing every time and you can audit why. Litify's AI agents and Agentforce are probabilistic: they read your records and produce judgements. Both are useful, but agents read the records deterministic automation creates, so getting this layer right first is what makes the AI layer worth turning on at all.