CASE 02 / CONNECTED VIEW
CUSTOMER OPERATIONS · WORKFLOW DESIGN · SQL · POWER BI
One customer record. The operations behind it.
The prototype brings 120 follow-up actions, their owners, and the customer records behind them into one review. SQL and Power BI use the same fictional source model.
Explore the connected workspace ↓Operational problemCustomer context, requests, ownership, and follow-up are disconnected
What I builtA personal and team workflow backed by a 10-table model and Power BI report
Decision this supportsWhich follow-up is blocked, and who has the context to move it?
CUSTOMER-OPERATIONS WORKSPACE
From customer record to owned next step.
Individual views show what each person owns. The connected team view shows where work is blocked, what context is missing, and who needs to answer the next question. The prototype is platform-neutral; an optional Salesforce configuration map is included below as one possible implementation.
Modeled snapshot: December 31, 2025. The Riverside readiness example retains its September 10, 2025 snapshot. Task counts are fixed to the modeled date.
MY WORK
Noah Brooks
All assigned accounts · featured account A006QUESTION WORTH ASKINGWhich Riverside quantity is customer-confirmed before the commitment moves forward?
Open connected record ↓Generated from a visible record condition and linked to the customer, request, and source evidence—not from an unsupported prediction.
CONNECTED ACCOUNT
Active customerWestbridge Group
Source Account ID · A006- ARR
- $150K
- Modeled risk tier
- High
- Adoption change
- −0.6 pts
- Open or escalated cases
- 0
Block Ready status without an account, request type, applicable location, customer confirmation, and source evidence.
Flag open requests sharing Account, Location, request type, and received date before another record is created.
The simulation shows a queue and follow-up target. Task creation is described in the optional implementation map.
Track owner and status changes while preserving source evidence, follow-up work, and final resolution.
OPTIONAL CRM IMPLEMENTATIONHow this workflow could be configured in SalesforceObject mapping, validation, routing, Flow, reports, and acceptance tests
The workspace above is a conceptual customer-operations prototype, not Salesforce Lightning and not evidence of a deployed org. The supporting specification maps the same workflow to standard and custom Salesforce objects as one possible implementation path.
View optional Salesforce specification ↗SUPPORTING ANALYTICS
One reporting model across the workflow, SQL, and Power BI—with published totals checked against the Excel case studies.
The Connected View workspace, SQL model, and Power BI files use the same source IDs and record definitions. North Star remains a standalone workbook with its original ACC-### IDs; the shared portfolio totals and five named queue accounts are reconciled explicitly rather than presented as row-for-row lineage. Salesforce appears only as an optional implementation map—not as a second product or a claim of deployment.
MeasureWorkflow recordSupporting sourceVerified value
Customer accountsAccount recordSQL + Power BI60
Operating locationsLocation recordSQL + Power BI74 · 15 Westbridge
Follow-up workAction recordactions.csv + Power BI120 · 38 open · 11 overdue
Support historyCase recordcases.csv + Power BI470 · 49 escalated
Decision historyRequest recordWho Decides? + SQL44 requests
Modeled review groupPortfolio viewNorth Star Excel + Power BI22 accounts · $4.149M ARR
Leadership subsetReview queueNorth Star Excel5 accounts · $2.358M
Readiness review evidenceEvidence recordIn Context evidence pack32 Riverside + 4 account context
The supplied fictional risk score creates the review group; it does not predict churn or lost revenue. Workspace ownership and follow-up views use the same 120 action rows as the SQL and Power BI files.
RELATIONAL ARCHITECTUREInspect the underlying data modelDimensions, activity tables, relationships, and record grain
DATA MODEL
Why I kept the tables separate
Accounts, locations, cases, actions, and decisions do not represent the same kind of record. Keeping them in related tables—and joining them only where the IDs match—lets the report connect the work without inflating counts or ARR.
DIMENSIONAccounts60 rows · one per customer
DIMENSIONLocations74 rows · 15 for Westbridge
DIMENSIONPeopleRecorded title + formal authority
DIMENSIONDatesShared reporting calendar
ACTIVITYMetrics · Cases · Actions · Requests · EvidenceSeparate grains, shared IDs
DESCRIPTIVE BRIDGERelationshipsShows access patterns, not why someone acted
FILES + QAInspect the build files and reconciliation checksSQL, Power BI, DAX, source data, and complete build pack
FILES + QA
How I built and checked the model
Schema and analytical queries
Primary and foreign keys, constraints, indexes, joins, CTEs, conditional aggregation, latest-record logic, and window functions.
View SQL queries ↗Complete three-page project
The cleaned .pbip project includes the semantic model, desktop and mobile layouts, source workbook, DAX measures, and opening instructions.
Download Power BI project ↓Download source workbook ↓Download DAX measures ↓Visible reconciliation checks
60 accounts, 22 accounts in the modeled High-risk group, $4.149M in group ARR, a $2.358M top-five subset, 470 cases, 11 overdue actions, and 44 decisions all reconcile.
Download model + build pack ↓Fictional, intentionally linked dataset—not company findings or client results. The download is a Power BI Project (.pbip) with its source workbook and setup notes. The modeled risk group creates a review priority; it is not a prediction of lost revenue.