Skills Data and integration
Modelling support data for a warehouse
Support data in a warehouse produces disagreeing numbers faster than almost any other domain, and the cause is nearly always the same: the grain of a table was never stated, so two people joined it two ways and both got a defensible answer.
npx rulebase-skills install cx-warehouse-modelingWhen to use it
Reach for this when someone says any of these — they are the phrases the skill itself triggers on:
- “model our support data in the warehouse”
- “build dbt models for tickets”
- “our support metrics disagree between dashboards”
How it works
The method, in the order the skill runs it. The full procedure — tables, worked examples and the edge cases — is in the skill itself.
State the grain of every table, in the table
The single highest-value convention in this domain. Every model gets a one-line grain declaration, and it belongs in the model's own documentation rather than in a wiki.
The canonical schema is the staging layer, not the mart
If your exports emit the canonical conversation schema, that shape is your staging layer — one stg_ model per source, all conforming to the same columns, with the vendor's raw values preserved in the *_raw fields beside every normalised one.
The date columns, and why there must be several
Every conversation has at least four meaningful timestamps, and picking one as "the" date is the second-largest source of disagreeing numbers: Event time, Record time, Ingest time, Resolution time.
Late-arriving and mutable data
Support records are mutable for their whole life. A ticket opened in January can change in August: status, assignee, tags, and even message content after a redaction.
Metrics belong in one place
The reason two dashboards disagree is almost always that each computes the metric itself.
Related skills
Free and open source, and vendor-neutral — it reads the conversations from whichever helpdesk you already run. Browse all 149 skills · connect your helpdesk over MCP · source on GitHub
