Every Case model decision is a reporting decision
The shape you give the Case object in the first month decides which questions you can answer in year three. A support director will ask how many billing disputes ended in a refund last quarter, and the answer either falls out of a report in ten minutes or takes an export, a spreadsheet and a caveat.
Most of these decisions are cheap when you make them. Choosing a record type takes a minute. Deciding that warranty claims live on Case alongside password resets costs nothing today, and costs a quarter of somebody's time to unwind four years on, once the two kinds of work have grown different automation and different ideas about what closed means.
Some of it really is reversible. Renaming a picklist value is a Tuesday afternoon. Splitting one object into two after three years of history is a project with a data migration and a reporting rebuild. Most of the skill in a Service Cloud implementation is knowing which side of that line a decision sits on.
One object or two, and the test that settles it
The question arrives early. Field service wants repair visits tracked. Billing wants invoice disputes. Legal wants product complaints logged and retained. Each sits close enough to a support request that the default answer becomes another record type on Case, and often that default is right.
The test that holds up asks whether the two kinds of work share a lifecycle and a reporting question, rather than whether they sound similar to the people describing them in a workshop. Shared lifecycle means the same status progression carries the same meaning for both, and that routing and escalation apply without a stack of exceptions. Shared reporting question means somebody genuinely wants one number across both.
Record types on one object buy shared automation and one place agents look, and cost you a page layout serving every variation. Separate objects buy clean fields and clean reporting per kind of work, and cost you duplicated routing plus an agent who has to know where a piece of work landed before finding it. Splitting one object into two after several years is the expensive direction, because the history never moves cleanly. The data model that outlives the CRM usually earned its longevity by staying narrow on day one.
What breaks when the customer is nobody yet
Cases hang off Account and Contact, and often off Asset as well. That wiring carries most of the value in the object. Entitlement checks, sharing and the agent's view of who is on the phone all depend on the Case pointing at a real Contact under a real Account.
Then a message arrives from a person who exists nowhere in the org. A tenant in a building your facilities customer manages. A consumer who bought through a distributor and now has your support address. Creating a Contact on the fly keeps the agent moving and guarantees duplicates, because the same person writes in again from another address and no matching rule catches every variation.
Holding unmatched work in a queue with no Contact keeps the database clean and moves the cost onto whoever works that queue, which in practice means the queue grows. Person accounts handle the consumer case properly, cannot be switched off once enabled, and reach into code that assumes an Account has no first name. If duplicates are already your problem, read what a shared customer record really needs before deciding the fix is a new object.
Parent cases are for shared causes, not task lists
Parent and child Cases get used for two purposes, and only one survives contact with reporting. The version that works: fifty customers report the same outage, each gets a Case because each needs their own communication and their own resolution time, and all fifty point at one parent tracking the underlying cause. Close the parent and you have a defensible answer to how many customers one defect touched.
The version that rots is task decomposition. An agent opens a Case, then opens three children for the steps, one for the hardware order, one for the site visit, one for the refund. Case volume triples, average handle time stops meaning anything, and every backlog report counts the same work twice. Steps in a process belong in tasks or in a purpose-built work object.
Parenting is among the easier things to correct later, which makes it a good place to be strict early. Reparenting is a data operation and the counts can be adjusted afterwards. What never repairs itself is three years of volume metrics nobody trusts.
Entitlements and milestones are real machinery
Entitlements, service contracts and milestones form a genuine subsystem with real administrative weight. Entitlement processes need versioning. Business hours and holiday calendars need maintaining. Milestone completion has to be triggered by something reliable, and when that breaks, your first response clock either stops early or never stops at all.
They earn their weight when service commitments are contractual and measured by somebody outside your team. If a customer agreement specifies a four hour response on severity one and a quarterly review checks performance against it, model the commitment properly. The alternative is a formula field that counts elapsed time and quietly ignores weekend hours.
When commitments are internal targets, the machinery costs more than it returns. A team that wants to know how often it replies within a day can get that from a timestamp and a report. Turning entitlements on for that buys an administrative load somebody owns after the consultant leaves, and the usual outcome is milestone rules nobody has touched since go live.
Why the Type, Reason and Status picklists rot
Picklist rot has a specific mechanic. Every team that joins the support org adds the value it needs. Nobody removes one, because removing a value breaks historical reports and somebody always objects. Three years in, Type has forty values, eleven of them used once and four meaning the same thing in different words.
The design that survives keeps the reporting dimension small and pushes specificity somewhere else. Type answers the question a director asks, which is how work splits into five or six buckets. Reason explains why within a type and can afford more values. The fine-grained classification a product team wants belongs in a separate field that team owns, where it can churn without disturbing the number on the director's dashboard. Agreeing that split as an analytics requirement is the cheapest hour in the build.
Status is the strictest of the three, because automation and reporting both key off it. Adding a status value changes the lifecycle, and the lifecycle is what makes one object viable for several kinds of work. Picklists stay reversible in the narrow sense and permanent in the useful one. You can deactivate a value this afternoon, and you can never recover what the people who picked it meant. Blank and misused values carry information too, and the support signal hidden in a blank field is often the first sign a picklist stopped describing the work.
What to check in an org you inherited
Run one report. Group Cases opened in the last twelve months by record type and by Type, sort ascending by count and read the bottom of the list. Every combination with fewer than twenty Cases in a year is either a kind of work that has no business on this object or a picklist value somebody added and forgot.
Then count Cases with no Contact, and Cases whose Contact was created on the same day as the Case. The first tells you how much work arrives from people you cannot identify. The second tells you how fast you are manufacturing duplicates. If that number is high and nobody owns the merge queue, you have a duplicate rate rather than a duplicate backlog, and it compounds every month.
Last, open the parent Case list and read ten of them properly. If the children are steps in a process instead of customers affected by one cause, you have found why the backlog numbers never reconcile with what the team says it is doing. None of these checks takes more than an afternoon, and each points back to a decision somebody made years ago in a meeting where it felt small enough to settle in a minute.
