Two populations in one table
Putting ServiceNow CSM and ITSM on one CMDB is the right starting position for most companies, and the saving is genuine. One configuration item model, one set of relationship rules, one discovery investment, one place an engineer looks when something breaks. The trouble arrives later, from the same direction every time.
ITSM describes infrastructure your organisation owns and operates. Servers, databases, network hardware, the business services your support groups get paged for. You control that lifecycle from purchase order to decommission, and discovery can see most of it. CSM describes things a customer owns or consumes. A machine in their building, a subscription they pay for, an entitlement that expires on a date your finance system knows before your platform does.
One table now holds two populations with different owners, different sensitivity and different clocks. A stale internal CI costs an engineer an afternoon. A customer CI visible to the wrong account costs a contract conversation. Deciding where ITSM ends and CSM begins stops being a modelling preference the moment both applications read from shared data.
One person can be an employee and a customer contact
ITSM runs on a people model of users and groups. A user record, membership in assignment groups, a manager reference for approvals, roles that decide what the person can open. CSM adds account, contact and consumer on top. A contact is a user record joined to an account. A consumer is a person you serve with no account behind them.
A single human can legitimately be both. The IT manager at a subsidiary that buys your product. Your own employee who holds a consumer service contract with the division down the hall. The instinct is to create a second user record so the roles stay tidy, and it causes more damage than the overlap ever would. Fork the identity and you get two password resets and two sets of case history nobody reconciles.
What breaks is the visibility logic hanging off that shared record. If the portal decides what to show by reading the contact's account, and the same user sits in an internal assignment group, you need to know which context wins on every page. Getting the account hierarchy right early makes that tractable, because parent and child visibility is the rule most portals get wrong first.
Configuration item or install base
The argument nobody wins at the whiteboard is whether customer-owned equipment belongs in the CMDB as configuration items or in install base and sold product records. Both answers are defensible. The honest tiebreaker is how much operational dependency mapping you actually perform on customer assets, and most teams assume they will do far more than they ever do.
If you map real relationships across customer equipment, a controller at a site depending on a gateway depending on a circuit, and use them to work out impact when a case arrives, configuration items earn their place. You get the relationship engine, dependency views and the impact calculation ITSM already runs. If all you need is a serial number, a warranty end date, an entitlement and an address, install base carries that.
Be clear about reversibility, because this one is expensive to undo. Moving tens of thousands of customer assets from install base into the CMDB later means rewriting references on closed cases, re-pointing every integration that carries the asset identifier, and explaining why reporting history splits at a date nobody chose. Most often I find a CMDB full of customer records that only ever answer what serial number the customer has.
Permissions decide whether this architecture holds
The rule to design against is simple to state and tedious to enforce. A customer must never resolve a relationship path that leads into internal infrastructure. Not a table they can query, not a related list they can expand, not a dependency view that walks one hop upstream into the shared database their instance sits on.
The leaks turn up in the same three places. Reference qualifiers on the customer case form that quietly return every CI rather than the ones tied to that account. Related lists on portal record pages, which inherit read access from the parent table and will happily show the incidents attached to a CI. And the relationship table, which teams secure last because it holds no obvious customer data.
Write the access rules on the relationship table before anywhere else, because that table is how a curious portal user gets from their own asset to yours. Then check read access on every related list a customer can reach, and check again after any portal widget change. The discipline that keeps access requests governed internally applies to the portal, where a mistake is visible outside your company.
Two truth sources with different refresh rates
Internal CIs arrive from discovery, on a schedule, with an identification and reconciliation engine deciding what matches what. Customer assets usually arrive from another system entirely, an order management platform, an ERP, sometimes a field service application, on a weekly batch or an event trigger. One table, two truth sources, two refresh rates, one set of reconciliation rules unless somebody builds otherwise.
Set data source precedence deliberately and confirm that no discovery source holds authority over the customer classes. The failure worth guarding against is a discovery run deciding an asset it cannot see has gone away, because a machine in a customer's building will never answer a scan from your network. Mark those classes as maintained externally.
A stale record means different things on each side of that line. A stale internal CI sends an engineer to a rack that is already empty. A stale customer asset sends a field engineer to a site with the wrong firmware in hand and a four hour drive behind them. Both grow out of the same fight over who owns the CMDB, except the customer side adds a party who never attends your meetings.
Domain separation is heavier than it looks
Domain separation earns its keep in a narrow set of cases. A managed service provider supporting customers who compete with each other and carry contractual isolation requirements. A support organisation where each customer needs its own catalogue items, assignment rules and notification content rather than a variation driven by a field. Regulated arrangements where an auditor wants structural separation and will not accept access rules as evidence.
For a company that sells products to customers and supports its own staff in one instance, scoping and access control usually carry the load. An application scope boundary, access rules on the tables and the relationships, and a portal that only ever queries through an account filter. That combination is easier to test, and testing keeps customer data where it belongs.
Teams reach for domain separation early because it promises certainty, and it is heavy once it lands. Every script that moves data across domains needs thinking about. Every upgrade regression takes longer. Every new developer needs the model explained before they can write a query with confidence. Turning it off later is technically possible and practically rare, so earn it with a named requirement rather than a feeling about risk.
Walk the path a customer contact can walk
Here is the test worth running before anyone calls this architecture finished. Take a real customer contact from a production copy, impersonate that user in a sub-production instance, open a case against one of their assets, then click every related list, every reference lookup and every dependency view the portal renders. Keep going until you hit something internal or run out of links.
Plenty of instances fail inside four clicks, and rarely at the obvious place. The case record behaves. The asset record behaves. Then a related list on the asset shows an internal incident, or a dependency view resolves the customer's equipment up to the shared platform service it reports into, and an outside user is reading the name of a server in your data centre.
Repeat that walk after every upgrade and every portal change, and write the click path down so somebody else can run it without you. If you are also planning to let agents read this CMDB and act on what they find, get the data right before the agents arrive, because an automated reader follows relationship paths faster than any curious customer.
