Matter management is a data model. Everything else is a screen on top of it.

Yes, within limits. Salesforce does not ship a matter object, but it ships everything needed to build one: custom objects and relationships, record types, sharing and field-level security, approvals, automation, tasks, files and reporting. A well-configured native model handles matter records, stages, tasks, documents and reporting perfectly well. What you are taking on is authorship of the legal logic — statute and court-date rules, matter templates, legal invoicing and trust handling all become things your firm specifies and maintains rather than things a vendor updates. That is a reasonable trade for a straightforward practice and a poor one for a complex litigation or billing operation.

At minimum: the matter itself, the client it belongs to, the parties related to it — including opposing parties, which must never be merged into client records — the tasks and deadlines derived from it, the documents bound to it, and the time and cost entries recorded against it. Most firms also need matter types or record types per practice area, a sub-matter or grouping structure, and a rate or fee-arrangement structure. Getting the party model right is the single most common gap we find in existing orgs, because it is what conflict checking and relationship reporting both depend on.

As data derived by the system from a trigger event, not as reminders typed into a personal calendar. A date rule takes the triggering event — incident date, filing date, service date — and produces the dependent deadlines for that matter type and jurisdiction, which then appear on the matter, on team deadline views and in the calendars people actually use, with reminders and escalation when nothing moves. The rules themselves remain your firm's professional responsibility: we build the mechanism and configure the rules your practice specifies, and we recommend that the firm reviews them as part of its own risk process rather than treating any system as the authority.

Yes, and it is treated as the highest-risk part of the project. Open matters carry live deadlines, work in progress and financial balances, so they are migrated with their current stage mapped deliberately, their deadlines recalculated or carried across and checked individually, and their balances reconciled against the source system. Closed matters load as history and are far more forgiving. We run a test load and a validation pass first, keep a parallel period before cutover, and leave the legacy system read-only rather than switching it off — so there is always a reference copy.

Salesforce provides the mechanisms — role hierarchies, sharing rules, record-level and field-level access, restricted visibility on individual records, and audit trails on changes. A matter can be restricted so that only its assigned team sees it, including from partners above them in the hierarchy, which is the technical basis for an ethical wall. Whether your obligations are met depends on how those controls are configured against your specific requirements, so we design and document that configuration and expect your risk or compliance function to review and sign off on it. We build to the rule; we do not decide what the rule should be.

The structure is the same and the economics invert. A firm's matter produces revenue, so the model emphasises time capture, rates and realization. An in-house matter consumes budget, so it emphasises intake triage from the business, the decision to handle work internally or send it out, outside-counsel budgets and accruals, and invoice review against billing guidelines. The matter record, its parties, deadlines and documents are structurally identical — which is why one platform can serve both, and why in-house teams can often build on the Salesforce org their company already runs.

A focused implementation — core matter management, billing setup and baseline reporting — typically runs 6–10 weeks. The variables that extend it are the number of matter types needing genuinely different lifecycle logic, the volume and condition of matters being migrated, how many integrations are in scope, and how much of the requirement falls outside what configuration can do. Route matters too: a packaged legal application reaches a working baseline faster, while a native or custom model spends more of its time in design. We scope against your requirements before starting.