Customer Data: Accounts, Contacts, and Case Management
The data model you must be able to draw
An Account is the organization you support - it extends Company (core_company) and supports a parent/child hierarchy so a subsidiary rolls up to a parent account. A Contact is a named person at an account and extends Customer (csm_customer), which extends User (sys_user) - that is why contacts can log in to the portal, have email addresses, and be assigned roles. A Consumer is also a Customer but is a business-to-consumer individual with no account relationship. Both contacts and consumers are customers; only contacts belong to accounts.
Case relationships and entitlements
A case references the account and the contact (or consumer) it was opened for. Those references do real work: they drive which entitlements and SLAs apply, which sold products/install base records can be selected, and which knowledge the requester sees. Entitlements define the support terms (coverage, hours, response targets) for an account or a specific product; SLAs attach to them. Traps appear when a question asks about "the person who reported the case" (contact/consumer on the case) versus "the company being served" (account), or when a scenario silently has an account but no contact - a case can exist without a named contact.
Managing the case
Agents progress the case through states, add work notes versus additional comments (internal versus customer-visible), link related cases, and record the resolution. Closing without resolution notes, or confusing comments with work notes, are classic wrong answers.
Worked rule of thumb: B2B scenario → Account + Contact; B2C scenario → Consumer only. If the question mentions a person's login, think User-extended Customer; if it mentions a company hierarchy, think Account.