# Connected View — Optional Salesforce Implementation Map

Connected View is a platform-neutral customer-operations workflow prototype supported by Excel, SQL, and Power BI. This optional specification shows how the fictional scenario could be translated into Salesforce configuration. It is a learning and implementation-planning artifact, not evidence of a configured or production Salesforce org.

## 1. Record model

### Standard objects

- **Account** — one customer organization. `External_Account_ID__c` stores the source-system key.
- **Contact** — customer and internal contacts related to the Account.
- **Task** — follow-up created by Flow and assigned to the request owner or queue member.

### Custom objects

- **Location__c** — child of Account; one record per independently managed operating location.
- **Customer_Request__c** — operational request related to Account and, when applicable, Location__c.
- **Evidence__c** — source record related to Customer_Request__c, with source type, source date, reference ID, and review state.
- **Review_Question__c** — a traceable question created from a missing, conflicting, stale, duplicate, or unassigned record condition; related to the request, Account, owner, and team queue.

## 2. Customer Request fields

| Field | Type | Purpose |
|---|---|---|
| Account__c | Required relationship | Customer organization |
| Location__c | Lookup | Required for location-specific work |
| Request_Type__c | Picklist | Commitment readiness; Support escalation; Approval exception |
| Priority__c | Picklist | Standard; Urgent |
| Status__c | Picklist | New; Needs information; Ready; In progress; Resolved |
| Customer_Confirmed__c | Checkbox | Confirms customer or location acknowledgment |
| Source_Record_Attached__c | Checkbox | Indicates inspectable source evidence exists |
| Assigned_Queue__c | Text or formula | Routing result displayed for review |
| Received_Date__c | Date/time | Intake and duplicate matching |
| Resolution__c | Long text | Final disposition and context |

## 3. Validation rule

Prevent a request from entering `Ready` status when required context is absent.

```text
AND(
  ISPICKVAL(Status__c, "Ready"),
  OR(
    ISBLANK(Account__c),
    ISBLANK(TEXT(Request_Type__c)),
    NOT(Customer_Confirmed__c),
    NOT(Source_Record_Attached__c),
    AND(
      ISPICKVAL(Request_Type__c, "Commitment readiness"),
      ISBLANK(Location__c)
    )
  )
)
```

User message: `Add the required account, location, customer confirmation, and source evidence before moving this request to Ready.`

## 4. Duplicate prevention

Before creating a request, use Flow to check for an unresolved Customer_Request__c with the same Account__c, Location__c when present, Request_Type__c, and received calendar date. When a match exists, direct the user to the existing request instead of silently creating another record. A standard matching and duplicate rule can provide a second warning on the stable identifying fields.

## 5. Queues

- Customer Operations
- Customer Support
- Sales Approvals

## 6. Record-triggered Flow

Run after creation, or when request type, priority, account, location, confirmation, attached-evidence flag, or status changes. Use a before-save step for field updates and an after-save step for Task handling. The following is a proposed design, not a deployed Flow.

1. If status is Resolved, skip readiness/routing and new Task creation. Close the linked follow-up only after its resolution requirements are met.
2. Check context. Mark incomplete requests Needs information; set complete New or Needs information requests to Ready. Preserve In progress when context is still complete.
3. Route Commitment readiness to Customer Operations, Support escalation to Customer Support, and Approval exception to Sales Approvals.
4. Look up the follow-up Task by a stored Follow_Up_Task_ID__c. Update that Task if present; create exactly one only when no linked Task exists. Do not create another on status-only updates.
5. For urgent work, target the intake business date. Otherwise target three business days after intake, using configured business hours and holidays. Priority changes update the existing due date; routine edits do not restart the clock.
6. Write field changes only when values differ to avoid recursive updates. The after-save criteria must exclude changes solely to routing fields and the linked Task ID.
7. Preserve evidence, owner, status changes, Tasks, and resolution in the activity history. Validate Account/Location consistency before saving.

## 7. Account record page

Include the Account summary and primary Contact; Locations, open Customer Requests, Tasks, and Evidence related lists; the Activity Timeline; and an operational report chart filtered to the Account.

## 8. Reports and dashboard

- My Work: requests, blocked items, overdue Tasks, queue ownership, and assigned review questions filtered to the running user
- Connected Team View: workload, blocked work, aging, unassigned requests, and questions by owner and queue
- Open requests by queue and priority
- Requests blocked by missing context
- Urgent Tasks due today
- Request volume and median turnaround by request type
- Accounts with repeat exceptions
- Requests by location and current owner

## 9. Cross-platform reconciliation

The optional Salesforce map uses the Connected View source IDs and record definitions. North Star is an earlier standalone Excel workbook with ACC-### IDs, so its relationship to this model is verified at the published metric and named-queue level rather than described as row-for-row source lineage:

- 60 Accounts match the SQL and Power BI account tables.
- 74 Location__c records match the location table; 15 belong to Westbridge Group.
- 120 Tasks map to the action source: 38 Open and 11 Overdue across six named owners.
- 470 Cases match the support source: 49 Escalated.
- 44 Customer_Request__c records match the Who Decides? decision history.
- The modeled High-risk report contains 22 accounts and $4.149M ARR, matching the published North Star and Power BI totals.
- The leadership subset contains the same five named accounts and $2.358M ARR shown in the North Star workbook.
- The evidence pack contains 32 Riverside location records and four parent-account records (36 total), matching the In Context evidence pack.

## 10. Acceptance tests

1. A commitment request without Location__c cannot move to Ready.
2. A request without customer confirmation or source evidence remains Needs information.
3. Each request type routes to the intended queue.
4. Urgent requests create a Task due today.
5. A likely duplicate produces an alert before creation.
6. Account related lists show the correct locations, requests, evidence, and Tasks.
7. Connected View report totals reconcile to its source dataset by Account ID and Request ID; the North Star comparison is checked separately by published metric and named queue account.
8. Each user sees only the work and questions assigned to them in My Work, while the team dashboard retains the shared operational view.

9. Repeated saves and Flow re-entry update the linked Task without duplicating it.
10. Resolved requests remain resolved and do not create new follow-ups.
11. Adding missing context re-evaluates readiness; unrelated edits preserve the original intake-based deadline.
12. Business-day targets respect the configured holiday calendar.