Case Study 5: ScreenVault Studios - Worked Solution

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Reference Solution

This page compiles a worked answer for full-board study use. Compare the structure and trade-offs against your own attempt rather than treating it as the only acceptable design.

Solution Snapshot

Field	Detail
Open after	Scenario Paper
Difficulty	Intermediate
Primary pressure areas	Data, Integration, Marketing, and Governance
Study role	Worked solution and artifact reference
Core frameworks	9 Essential Artifacts + Five-Finger Method
Related pages	Case Study Overview, Presentation Notes, Q&A Preparation

Only Open After Your Own Attempt

If you have not yet worked through the scenario paper, stop here. Set a full 180-minute timer and build your own solution before reading this one.

Assumptions

1. Single org with Sales Cloud + Service Cloud + Marketing Cloud + Experience Cloud. Three business lines share content data and need cross-functional visibility. Single org avoids data sync complexity. Marketing Cloud (Engagement) replaces Mailchimp for both B2B and B2C journeys within the 5-month constraint.
2. Person Accounts enabled for B2C subscribers. Person Accounts represent the 2M subscribers as a single record per identity (Account + Contact merged). This is the only standard single-record pattern that lets a subscriber be both a consumer record and an Experience Cloud user backing record. Person Accounts enablement is irreversible and has org-wide impact, so it is escalated as a CEO-level decision at program kickoff. Business Accounts continue to represent B2B licensing partners and production vendors. The Account object uses RecordType to separate the three personas (Subscriber Person Account, Licensing Partner Business Account, Production Vendor Business Account).
3. Data 360 (formerly Data Cloud) for Snowflake integration. 50M streaming events/day stay in Snowflake. Data 360 connects natively via zero-copy, making subscriber engagement scores and content performance metrics available in Salesforce without data replication. Every Calculated Insight execution runs a Snowflake query, so Snowflake warehouse compute cost is an ongoing operational expense owned in the Finance cost plan.
4. Custom objects for content rights modeling. No off-the-shelf Salesforce product handles multi-territory, multi-window content licensing. Custom objects with Apex validation enforce rights conflict detection. Standard Contract is rejected because Contract status and line-item semantics do not map to multi-territory exclusivity windows; Subscription Management / Revenue Cloud is rejected as overkill for a 12K-contract volume and a single-domain pricing model.
5. Salesforce Mobile App Plus with Briefcase Builder for offline access. Production crews get Mobile App Plus (the offline-enabled Salesforce mobile product) with Briefcase Builder for offline sync of records. Mobile App Plus adds a per-user license line for the 200 crew, which is carried in the program budget. Briefcase Builder syncs record data only and is scoped at up to 50,000 records per user across all active briefcases; it does not sync ContentDocument, ContentVersion, or Attachments. For offline document access (e.g., permits, call sheets), the mobile app stages a managed document cache that pre-downloads permit PDFs to the device over Wi-Fi; the PDFs live as static assets on the device, not as Salesforce Files. Field Service is not required because there is no dispatch or work order workflow, and it would add unnecessary per-user licensing cost on top of Mobile App Plus.
6. MuleSoft Anypoint Platform for integration orchestration. Although total volume is moderate (~60K events/day across 8 systems), the integration requirements demand CDC-triggered bidirectional sync with the Rights DB, dead letter queues for failed financial postings, HMAC webhook verification, and structured error handling with retry policies. These capabilities require Anypoint Platform, not the lighter-weight MuleSoft Composer. Native connectors (Data 360 for Snowflake, Marketing Cloud Connect) handle the highest-volume paths directly.
7. External Client Apps (ECAs) for all new system-to-system integrations. Spring ‘26 disables new Connected App creation, so every integration in this greenfield program authenticates via an External Client App bound to a dedicated minimum-privilege Integration User. Any existing Connected Apps (e.g., the base Salesforce Mobile App) continue to work under their current configuration.

Key Architectural Decisions

Decision 1: Content Rights Data Model (D3)

The most critical design challenge. Content licensing involves overlapping dimensions: one title licensed to multiple partners across different territories, time windows, platform types, and exclusivity levels. A flat Opportunity model cannot represent this.

Approach: A dedicated Content Right object as the junction between Content Title and Account (licensing partner). Each Content Right record captures one specific grant: territory, window dates, platform type, exclusivity, and pricing. Apex trigger-based validation on insert/update checks for conflicts: overlapping exclusive rights for the same title, territory, and window.

Relationship choice and sharing implications: Content Right is designed as a master-detail junction with two parents. Account (Licensing Partner) is the primary master-detail with sharing setting Read/Write - this means a licensing rep needs Read/Write access to the partner Account to create or edit a Content Right, which matches the rep’s normal ownership of their partner Accounts. Content Title is the secondary master-detail with sharing setting Read - this means the rep needs only Read on Content Title (satisfied by the Public Read Only OWD) to attach a Content Right. With Account as primary, the Content Right record owner is derived from the Account owner, and partner users in Experience Cloud see only their own Account’s Content Right children through record ownership, not through an additional sharing set. If instead Content Title were primary, every Content Right would inherit Public Read Only from Content Title and every partner would see every deal - a catastrophic data leak. Content Right is therefore declared with Account as primary and Content Title as secondary; the OWD line “Controlled by Parent (Account as primary master-detail)” is explicit.

Rejected: Modeling rights as Opportunity Products. Products lack the multi-dimensional constraint logic needed, and conflating rights with the deal pipeline makes reporting unreliable. Also rejected: modeling Content Right as a lookup-only junction, because lookup-only would lose the cascade-delete safety and the automatic sharing inheritance from Account that the partner portal design depends on.

Decision 2: Snowflake Integration via Data 360 (D5)

50M streaming events/day cannot enter Salesforce objects. Data 360 provides zero-copy access to Snowflake, making viewer behavior available for segmentation, churn scoring, and content analytics without moving raw data.

How it works: Data 360 maps Snowflake tables (viewer profiles, content performance, engagement scores) as data lake objects. Calculated insights generate subscriber-level churn scores and engagement segments. These scores are accessible in Salesforce via related lists and flow-based automation (e.g., create a case when churn score exceeds threshold).

Rejected: Batch ETL of aggregated data into custom objects. This creates stale data (daily at best), requires ongoing maintenance, and misses the real-time segmentation capability Data 360 provides.

Decision 3: Marketing Cloud Timing and Architecture (D4/D5)

Mailchimp expires in 5 months, creating the hardest timeline pressure in the program. Marketing Cloud Engagement must be operational for at minimum B2C subscriber campaigns by month 5.

Approach: Accelerate Marketing Cloud implementation. Phase 1 (months 1-5) delivers B2C journeys (welcome, re-engagement, winback) using Marketing Cloud Connect to sync subscriber records. Phase 2 adds B2B partner journeys. Data 360 feeds behavioral segments into Marketing Cloud for behavior-triggered campaigns.

Artifact 1: System Landscape

Figure 1. System landscape for ScreenVault Studios showing a single Salesforce org integrating the full media lifecycle from B2B content licensing through Sales Cloud and a retiring Rights Management DB, to D2C subscriber operations via Service Cloud and Marketing Cloud with Data 360 zero-copy on Snowflake, and production crew management via a mobile app replacing Google Sheets.

Artifact 2: Data Model

Figure 2. Data model for ScreenVault Studios with Content Right as the central licensing junction between Account (primary master-detail) and Content Title (secondary master-detail), tracking territory, platform type, exclusivity, and rights windows for 12,000 active contracts, with Apex trigger-enforced conflict detection blocking overlapping exclusive rights grants before save.

Key design points:

• Content Right is the central licensing object. It is a master-detail junction with Account as primary (sharing = Read/Write) and Content Title as secondary (sharing = Read). Each record represents one specific rights grant with territory, window, platform type, and exclusivity. The Opportunity relationship is a lookup, not a master-detail, because a Content Right can exist without an open Opportunity (renewals, amendments, manual grants) and cascade-delete from Opportunity would be destructive. Choosing Account as the primary master drives record ownership from the partner Account owner, which makes the Experience Cloud sharing story simple: partner users who can see their own Account automatically see their own Content Right children, without a redundant sharing set.
• Rights conflict detection: Before-insert/before-update Apex trigger queries existing active Content Right records for the same Content Title + Territory + overlapping date range where Exclusivity = Exclusive. If a conflict exists, the trigger blocks the save and surfaces a clear error message.
• Subscription is a custom object (not standard Opportunity or Contract) because subscriber lifecycle differs fundamentally from B2B sales pipeline and from Contract’s renewal/line-item semantics. ChurnScore and EngagementScore are fields on Subscription populated by Data 360: Calculated Insights compute churn and engagement scores in Data 360 and Data 360 Enrichment writes the values back to Subscription.ChurnScore__c and Subscription.EngagementScore__c in CRM. Engagement Score is not a separate CRM object, has no CRM-side OWD, and does not appear in the ER diagram as an entity - it is a Data 360 Calculated Insight surfaced in CRM through enrichment.
• Account model with Person Accounts for subscribers. Business Accounts carry the 500 Licensing Partners and the Production Vendors. Subscribers are Person Accounts (1 record = 1 identity). Only the 100K-200K subscribers who actually register for the self-service portal are provisioned with Customer Community Plus Login licenses; the rest stay as Person Account records without a portal user. Account RecordType still separates the three personas (Licensing Partner, Subscriber Person Account, Production Vendor) for layouts, automation, and reporting.
• Content Title’s ExternalCMSId field links to the source CMS for metadata sync.
• Location-based features: Production has a Geolocation field capturing the shoot location. Crew Assignment stores LastKnownLocation updated via mobile sync when connectivity is available. Production managers can query nearby crew members using SOQL DISTANCE and GEOLOCATION functions. Equipment is a child object of Production with check-in/check-out status tracking; crew members update equipment status via the mobile app (including offline, synced on reconnect).
• Equipment and Crew Assignment relationship choice. Production OWD is Public Read (not Public Read Only) because crew members need to update their own Equipment and Crew Assignment records from the field without having Edit on Production itself. If Production were left at Public Read Only with children on master-detail “Controlled by Parent,” crew members could not write to Equipment or Crew Assignment without Edit on Production, which would violate the intent (crews should not be editing production budgets or schedules). The chosen pattern: Production stays Public Read, Equipment and Crew Assignment are lookup relationships with their own Private OWD and criteria-based sharing that opens them to the assigned crew. An Apex without sharing service writes mobile updates for crews whose sharing does not otherwise permit writing their own records.
• Equipment tracking: The Equipment object supports check-out/check-in workflows on mobile. When a crew member checks out a camera or lighting rig, the record captures who, when, and which production. Check-in clears the assignment. Equipment status reports show utilization across active productions.

Artifact 3: Role Hierarchy & Sharing Model

Figure 3. Role hierarchy for ScreenVault Studios separating the licensing branch (regional managers and reps with private Account and Content Right access through Account-as-primary master-detail inheritance) from the consumer branch (subscriber ops and marketing with separate private Subscriber Person Account access), with production crew on a distinct branch accessing Production (Public Read) and their own Crew Assignment and Equipment records through criteria-based sharing, and a GDPR DPO branch outside all revenue-reporting lines with explicit Privacy Center authority to cascade right-to-erasure requests across CRM, Data 360, and Marketing Cloud.

Object	OWD	Mechanism
Account (Licensing Partner - Business)	Private	Role hierarchy; licensing team ownership; owned by the rep, visible up the licensing branch
Account (Subscriber - Person Account)	Private	Owned by a dedicated “Subscriber Automation” integration user; Consumer Ops managers and support agents get Read/Write via role hierarchy + a criteria-based sharing rule to the consumer team public group
Account (Production Vendor - Business)	Private	Owned by Production Managers; visible to the production branch
Contact	Controlled by Parent	Inherits from parent Account
Content Title	Public Read Only	All employees need catalog visibility
Content Right	Controlled by Parent (Account as primary master-detail)	Account master-detail sharing = Read/Write; Content Title master-detail sharing = Read; record ownership follows partner Account; partner portal users see their own Content Right children automatically via Account ownership
Subscription	Controlled by Parent	Inherits from Subscriber Person Account
Opportunity	Private	Licensing team ownership
Case	Private	Queue-based assignment; consumer support team
Production	Public Read	Cross-team visibility; edit restricted to production team via profiles; not Public Read Only, so that children on lookup with own sharing can be updated from mobile without requiring Edit on Production
Crew Assignment	Private (lookup to Production)	Criteria-based sharing to the assigned crew public group; without-sharing Apex service handles offline mobile updates where the sharing reach is not otherwise sufficient
Content Performance	Public Read Only	One per title; cross-team analytics visibility
Equipment	Private (lookup to Production)	Criteria-based sharing to the crew assigned to the production; check-in/out tracked per crew member via mobile; without-sharing Apex service handles offline updates

Engagement Score note: Engagement Score is not a Salesforce CRM object. It is a Data 360 Calculated Insight (source: Snowflake viewing events) surfaced in CRM via Data 360 Enrichment writing to Subscription.EngagementScore__c. Because it is not a CRM record, it has no OWD row and does not appear in the ER diagram as an entity.

Key sharing decisions:

• Content Title is Public Read Only because licensing reps, marketing, production, and executives all need catalog access. Financial terms live on Content Right (private), not Content Title.
• Licensing financial data isolation: Content Right is Controlled by Parent with Account as the primary master-detail (sharing = Read/Write) and Content Title as the secondary master-detail (sharing = Read). A rep needs Read/Write on the partner Account (which they own) and only Read on the Content Title (provided by the Public Read Only OWD) to create or edit a rights record. Subscriber team cannot see licensing deal terms. Licensing team cannot see subscriber PII. Separation runs through role hierarchy branches and Account OWD.
• Permission Set for deal pricing: Content Right financial fields (LicenseFee, payment terms) use Field-Level Security restricted to Licensing and Finance profiles only.
• Partner portal (Licensing Partners): Partner users are Partner Community licensed users attached to the Licensing Partner Account via a Contact. Partner access is granted through sharing rules and the partner role hierarchy, not a sharing set. Sharing sets are the pattern for high-volume customer community users; partner users use role-based sharing because each partner Account’s users need to collaborate with each other and with the internal licensing reps who own the Account. A partner role (“Partner Executive -> Partner Manager -> Partner User”) is created beneath each Licensing Partner Account at user provisioning, and partners see only records owned by their own Account hierarchy. Content Right inherits visibility from the partner Account’s ownership, so partners see the catalog (Public Read Only) but only their own deal terms.
• Subscriber self-service portal (B2C): The 100K-200K registered subscribers access the self-service portal via Customer Community Plus Login licenses. Each registered subscriber is a Person Account login, so the same record that carries subscriber data is also the user backing record. Person Account access to Case, Subscription, and billing is scoped via a Customer Community sharing set and OWD=“Private.” No Content Right exposure.

Artifact 4: Integration Architecture

Figure 4. Integration architecture for ScreenVault Studios showing MuleSoft Anypoint as the sole integration layer orchestrating six external systems: bidirectional Rights DB sync transitioning from source-of-truth to decommission over nine months, nightly SAP ERP batch with deal-close triggers, daily CMS metadata sync, streaming platform and payment processor webhooks publishing Platform Events, and Data 360 zero-copy connector reading 50M Snowflake events daily for churn scoring.

System	Pattern	Direction	Protocol	Frequency / Volume	Details
Rights Management DB	Bidirectional sync	Both	REST API via MuleSoft + CDC	Real-time - 500 queries + 50 updates/day	Salesforce becomes primary on zero-discrepancy exit from the 30-day parallel-run (months 3-4); Rights DB then runs read-only as a safety net through month 9 before decommission. During the 30-day window, MuleSoft’s Salesforce CDC Connector subscribes to Content Right change events and pushes them to the Rights DB via REST, and a reverse polling/event path pulls any Rights DB edits back into Salesforce.
Content Management System	Request-Reply	Inbound	REST API via MuleSoft	Scheduled daily - 2K reads + 20 updates/day	Scheduled sync pulls title metadata daily. On-demand lookup via External Services for real-time catalog search.
SAP ERP	Request-Reply + Batch	Bidirectional	OData + SOAP via MuleSoft	Batch nightly + event on deal close - 200 txn/day	Deal closure triggers revenue schedule creation in SAP. Nightly batch reconciles financial data.
Snowflake	Zero-copy via Data 360	Inbound	Data 360 native connector	Continuous - aggregated extracts from 50M events/day	No data movement. Data 360 reads Snowflake tables directly. Calculated insights generate churn scores and engagement segments.
Streaming Platform	Event-Driven	Inbound	Webhooks via MuleSoft	Real-time - 5K subscriber events/day	Subscriber signup/cancel/payment webhooks publish Platform Events. Flow automation creates or updates Subscription records.
Payment Processor	Event-Driven	Inbound	Webhooks via MuleSoft	Real-time - 8K payment events/day	Payment success/failure webhooks update Subscription status and trigger dunning flows.
Marketing Cloud	Marketing Cloud Connect	Bidirectional	MC Connect	15-min sync intervals	Subscriber and partner records sync to Marketing Cloud. Journey triggers based on Data 360 segments.
Ad Sales Platform	Scheduled batch	Inbound	REST API via MuleSoft	Daily batch - 500 ad metrics/day	Daily pull of ad performance metrics linked to content titles.
AWS S3	Reference	Read-only	HTTPS/S3 API	On-demand (CMS references)	Content assets (artwork, trailers, documents) referenced by CMS. No direct Salesforce integration - accessed via CMS metadata links.

Rights DB transition plan: Months 1-3 - Salesforce reads from Rights DB as source of truth while building its complete copy via bulk load and CDC. Month 3 to month 4 - 30-day dual-write parallel run with daily discrepancy reporting against record counts, key-field checksums, and overlap validation; this is the scenario-required 30-day window. Month 4 - Salesforce takes over as source of truth on zero-discrepancy exit. Months 4-9 - Rights DB is read-only archive and reconciliation safety net. Month 9 - Rights DB decommissioned. Knowledge transfer from the Rights DB developer completes in months 1-2 (API reference, schema snapshot, data model notes) so the SI partner can maintain the interface if the developer departs before month 3. After month 4 the Rights DB takes no write traffic, so the single-developer retention risk is eliminated.

Artifact 5: Identity & SSO

• Employees (1,200): Corporate IdP (Google Workspace or Okta) via SAML 2.0. Single sign-on for Salesforce, CMS, and internal tools. Permission Set Groups assigned by department (Licensing, Consumer, Production, Finance).
• Licensing partners (500 accounts, ~2,000 portal users): Partner Community licensed users attached to Licensing Partner Accounts via Contact. Partner Community login with Salesforce Identity for smaller partners (self-registration with email verification, MFA via TOTP) and SAML federation with the partner’s own IdP for large partners (Netflix, BBC, Hotstar), where Salesforce acts as SP and the partner IdP authenticates. Partner role hierarchy and sharing rules, not sharing sets, grant record visibility.
• Subscribers (2M): Person Account records in Salesforce. Only the 100K-200K subscribers who actually register for the self-service portal are provisioned with Customer Community Plus Login licenses, metered by login events rather than named users to keep cost proportional to actual portal usage. Salesforce Identity handles authentication (email/password, MFA for sensitive actions). The streaming platform remains the primary identity provider for the streaming app itself; Salesforce only owns identity for the support and billing portal. The 2M total Person Account volume is inside the standard Salesforce scale envelope with appropriate custom indexes and avoids the impossible “users on standalone Accounts” pattern.
• Production crews (200): Same corporate SSO. Salesforce Mobile App Plus on BYOD devices with MDM-enforced device policies (screen lock, remote wipe). Mobile App Plus runs under the program’s ECA session policies.

Artifact 6: Data Migration Strategy

Phase 1 - Licensing Data (Months 1-4):

1. Export Rights DB data: 12,000 active contracts, 500 partner accounts, 1,800 content titles, and historical rights records.
2. Map Rights DB schema to Content Title, Content Right, and Account (Licensing Partner Business Account) objects. Partner accounts matched against existing 15 Salesforce accounts; remaining ~485 created new.
3. Content Title metadata loaded from CMS export (one-time bulk load, then scheduled sync).
4. Rights conflict validation: run Apex validation against all imported active rights to verify no pre-existing conflicts. Fix data quality issues before go-live.
5. Parallel run (month 3 to month 4): 30 days of dual-write via the integration layer as required by the scenario, with daily discrepancy reporting against record counts, key-field checksums, and rights conflict overlap counts. Exit at day 30 with zero unexplained discrepancies for three consecutive days. Salesforce becomes source of truth immediately on exit.
6. Rights DB runs read-only from month 4 through month 9 as a reconciliation safety net, then decommissions.

Phase 2 - Subscriber Data (Months 2-5):

7. Subscriber Person Account records created from streaming platform export: 2M records via Bulk API with the Person Account RecordType. No login credentials in Salesforce at load time - portal users are provisioned later on registration. Deduplication must happen pre-load (e.g., MuleSoft DataWeave dedup logic or Informatica matching) because Bulk API bypasses Salesforce Duplicate Rules. The integration layer deduplicates on email + streaming platform ID before any Bulk API upsert.
8. Mailchimp contacts mapped to Subscriber Person Accounts with consent status, opt-in history, and suppression lists transferred. Mailchimp automations and Content Builder assets cannot be migrated automatically - they are manually rebuilt in Journey Builder and Content Builder on the replacement Marketing Cloud instance during months 2-4 before cutover.
9. Marketing Cloud provisioned and configured by month 2. Journey Builder rebuilds of the Mailchimp automation set complete by month 4. B2C journeys (welcome, re-engagement) live by month 5 to meet Mailchimp expiry.

Phase 3 - Production Data (Months 8-12):

10. Google Sheets production data cleansed and loaded: active productions, schedules, crew assignments.
11. Historical productions loaded for Content ROI reporting (linking production cost to title revenue).

Artifact 7: Governance

Steering Committee: Monthly. CEO, VP Licensing, VP Consumer, CTO, CFO. Reviews program milestones, budget, and cross-team conflicts.

Technical Review Board: Bi-weekly. CTO (chair), lead admin, SI architect, integration lead. Reviews schema changes, integration designs, and automation logic.

Change Type	Approval	Lead Time
Schema / data model	Technical Review Board	1 sprint
Integration (new or modified)	Technical Review Board	1 sprint
Marketing journeys	VP Consumer + Marketing Manager	3 business days
Configuration (layouts, reports)	Lead admin	Same sprint
Emergency fix (P1)	CTO	Same day

Standards: Naming convention SVS_[Object]_[Purpose]. Apex test coverage 85% minimum. All automation via Flow or Apex (no Process Builder or Workflow Rules). Rights conflict logic in Apex only (not Flow) for testability and complex query performance.

Artifact 8: Environment Strategy

Environment	Purpose	Refresh
Full Copy Sandbox	UAT + performance testing with 2M subscriber records	Monthly
Partial Copy Sandbox	Integration testing (Rights DB, SAP, Snowflake connections)	Bi-weekly
Developer Sandbox (x2)	Core platform team + SI partner team	Sprint start
Developer Pro Sandbox	Marketing Cloud testing	As needed

CI/CD: Salesforce CLI + GitHub Actions. Branch strategy: main (production), release/* (UAT), feature/* (development). Deployments: Dev Sandbox -> Partial Copy -> Full Copy -> Production. No manual metadata deployments.

Marketing Cloud: Separate deployment process. Business units for B2B and B2C. Journey changes go through staging BU before production BU.

Artifact 9: Phased Delivery Roadmap

Figure 5. Phased delivery roadmap for ScreenVault Studios prioritizing rights management risk in Phase 1, with Marketing Cloud provisioning starting in month 1 of Phase 2 and a parallel Journey Builder rebuild of the Mailchimp automation set from months 2 to 4 so that B2C journeys go live in month 4 and Mailchimp cutover lands in month 5 (September 2026) ahead of its contract expiry, Data 360 and Snowflake zero-copy in Phase 2, and production crew mobile app and content ROI analytics in Phase 3, with GDPR compliance running as a 6-month cross-cutting workstream.

Sequencing rationale: Phase 1 addresses the highest business risk (rights management on a fragile system with a single developer), with the scenario-required 30-day Rights DB parallel run running from month 3 to month 4. Phase 2 starts at month 1 (not month 4) because the Mailchimp replacement work is on a strict deadline and the Marketing Cloud rebuild cannot wait - Marketing Cloud is provisioned in month 1 and the Journey Builder rebuild starts in month 2 while Phase 1 data model work proceeds. B2C journeys go live at month 4 and Mailchimp cutover is month 5, ahead of contract expiry. Data 360 connects from month 6 onward. Phase 3 is lowest risk and can absorb schedule pressure from earlier phases.

Governance & DevOps

Environment Promotion Flow

Figure 6. Environment promotion flow for ScreenVault Studios with two Salesforce developer sandboxes promoting through Partial Copy integration testing to Full Copy UAT (carrying 2M subscriber records and 12K rights contracts for realistic volume testing), alongside a parallel Marketing Cloud track from Developer Pro staging business unit to production business unit for B2B and B2C journey validation.

Branching Strategy

SVS operates three concurrent workstreams (licensing, subscriber/marketing, production) with overlapping phases. The branching model balances parallel development with stable releases.

Branch	Purpose	Merge Target
main	Production - deployed code only	N/A
release/phase-1, release/phase-2, release/phase-3	Release stabilization per program phase	main
develop	Integration branch - all feature work merges here first	release/*
feature/SVS-[ticket]-[description]	Individual feature work	develop
hotfix/SVS-[ticket]-[description]	Production emergency fixes	main + develop

Merge cadence: Feature branches merge to develop via PR with required code review (minimum 1 reviewer from the platform team). develop merges to release/* at sprint boundaries (2-week sprints). Release branches deploy to UAT for stabilization before production promotion.

Sandbox Strategy

Sandbox	Type	Purpose	Refresh Cadence	Data Seeding
SVS-DEV-CORE	Developer	Core platform team - data model, rights logic, Apex triggers	Sprint start	Minimal: 50 accounts, 200 content titles, 500 rights records
SVS-DEV-SI	Developer	SI partner - Experience Cloud partner portal, subscriber flows	Sprint start	Minimal: same as core + 100 portal users
SVS-INT	Partial Copy	Integration testing - Rights DB, SAP, CMS, Snowflake connections	Bi-weekly	Partial: 500 accounts, 1,800 titles, 5,000 rights, sampled subscriber data
SVS-UAT	Full Copy	UAT + performance testing with realistic data volume	Monthly	Full copy: 2M subscriber records, 12K contracts, all content titles
SVS-MC-STAGING	Developer Pro	Marketing Cloud journey testing (B2B + B2C)	As needed	Synthetic subscribers with engagement scores for journey testing

Data seeding notes: Rights DB integration testing requires realistic overlapping rights scenarios to validate conflict detection. The integration sandbox includes 200 intentionally conflicting rights records for regression testing. Subscriber data in UAT must include synthetic churn scores and engagement segments from Data 360 to validate marketing journey triggers.

Testing Strategy

Test Type	Coverage Target	Scope	Automation
Unit tests (Apex)	85% minimum (SVS standard)	Rights conflict detection, subscription lifecycle, engagement scoring triggers	Apex @isTest classes; run on every PR
Integration tests	All 8 external systems	Rights DB bidirectional sync, CMS metadata pull, SAP revenue posting, streaming platform webhooks, payment webhooks, ad metrics batch via MuleSoft MUnit; Data 360 zero-copy and Marketing Cloud Connect validated through their own admin tooling (Data 360 Setup monitoring + MC Connect health dashboard) because MUnit tests MuleSoft application logic and does not cover native connectors	MuleSoft MUnit tests + Data 360 + MC Connect admin validation; run before release branch merge
Performance tests	Sub-3s page load for partner portal; rights conflict check under 2s for 12K active contracts	Rights conflict query with full dataset, partner portal concurrent access (500 partners), Data 360 segment refresh	k6 load tests against Full Copy sandbox
UAT	All business-critical journeys	Licensing deal lifecycle end-to-end, subscriber churn detection to winback journey, production crew mobile offline sync	Manual test scripts with business stakeholders
Regression	Rights conflict detection suite	Every schema change to Content Right, Content Title, or Account triggers full regression	Automated Apex test suite (dedicated regression tag)

Center of Excellence & Ongoing Governance

SVS Platform CoE (established Phase 1, month 3):

• CoE lead: Internal Salesforce admin (1 of 3 existing) - becomes full-time platform owner post-go-live
• Members: 1 admin, 1 developer (internal), SI partner architect (advisory through month 14), integration lead
• Responsibilities: Approve all schema changes, review integration modifications, manage technical debt backlog, train new team members
• Release cadence: Production deployments every 2 weeks (sprint boundaries) for standard changes. Emergency fixes: same-day deployment with CTO approval.
• Change management: All non-emergency changes require PR approval from CoE lead. Schema changes and integration modifications require Technical Review Board approval (bi-weekly meetings documented in Artifact 7).
• Post-program maintenance: SI partner transitions to 20-hour/month managed services retainer for 6 months post-program completion. Knowledge transfer to internal team during months 12-14.
• Marketing Cloud governance: B2B and B2C business units managed separately. Journey changes require VP Consumer approval (B2C) or VP Licensing approval (B2B). No cross-BU journey deployment without Marketing Manager review.
• Rights DB decommission governance: Dual-write validation dashboard monitored daily during the 30-day parallel-run window (month 3 to month 4). Zero-discrepancy exit criterion enforced before switching Salesforce to source of truth at month 4. Rights DB runs read-only through month 9 as a reconciliation safety net, then decommissions. Rights DB developer completes knowledge transfer documentation (API reference, schema snapshot, data model mapping) by month 2.

Identity & SSO Flow

Internal Employee SSO (SAML 2.0)

Figure 7. Employee SSO sequence for ScreenVault Studios showing SP-initiated SAML 2.0 with Google Workspace or Okta as the corporate IdP, where the SAML assertion carries department group membership claims that Salesforce maps to Permission Set Groups, ensuring licensing reps, production crew, subscriber ops, and finance team members each receive the correct access scope on first login.

IdP choice: Google Workspace (existing corporate tool for all 1,200 employees) or Okta if SVS uses it. Google Workspace provides SAML 2.0 and directory sync natively. Department-based groups in Google map to Salesforce Permission Set Groups: Licensing, Consumer, Production, Finance, and Executive.

MFA: Enforced at the IdP level for all internal users. Google Workspace supports TOTP, hardware keys, and push notification. Salesforce-side MFA not required when IdP-enforced MFA is in place (counts as satisfying the Salesforce MFA requirement).

Licensing Partner Portal SSO

Figure 8. Licensing partner portal SSO sequence for ScreenVault Studios showing two authentication paths: Salesforce Identity with email/password and TOTP MFA for the 400+ smaller distributors who self-register, and SP-initiated SAML federation for major enterprise partners like Netflix and BBC where Salesforce acts as the service provider and the partner’s corporate IdP handles authentication and MFA enforcement.

Partner identity approach: Most partners (400+ smaller distributors) use Salesforce Identity with self-registration and email verification. Large partners like Netflix, BBC, and Hotstar that have their own enterprise IdPs federate via SAML. Salesforce acts as SP, and the partner’s IdP authenticates. This avoids forcing enterprise partners to manage yet another set of credentials.

MFA: Required for all partner portal users. Standard partners use TOTP (authenticator app). Federated partners rely on their own IdP MFA policies.

System-to-System Integration Auth

Figure 9. System-to-system integration auth for ScreenVault Studios showing OAuth 2.0 Client Credentials flow with MuleSoft Anypoint caching and auto-refreshing access tokens, each integration using a dedicated External Client App bound to a minimum-privilege Integration User whose profile and permission set group grant access only to the objects required (Rights DB Integration User to Content Title, Content Right, and Account only; SAP Integration User to Opportunity and revenue objects only), with HMAC signature validation rejecting unsigned inbound webhooks before any Salesforce write.

Auth strategy: As of Spring ‘26, Salesforce disables new Connected App creation in production orgs; all 8 new integrations in this greenfield program therefore use External Client Apps (ECAs). Each integration has its own ECA bound to a dedicated Integration User. Object-level access is enforced by the Integration User’s profile and permission set group, not by the app itself (ECA/Connected App OAuth scopes govern OAuth behavior, not CRUD) - this is the common trap a board will probe. Rights DB Integration User: Permission Set Group with Read/Write on Content Title, Content Right, and Account (Licensing Partner). SAP Integration User: Permission Set Group with Read/Write on Opportunity and revenue-related objects only. Integration Users have no UI access; their login IP ranges are locked to MuleSoft gateway IPs. Access token session length is governed by the ECA session policy rather than a hard-coded platform rule. This limits blast radius if any single integration credential is compromised.

Webhook inbound (Streaming Platform, Payment Processor): Webhooks validated via HMAC signature verification at the Anypoint layer before any Salesforce write. Invalid signatures are rejected and logged.

Production Crew Mobile Auth

Production crew members (200) use the same corporate SSO as all employees on Salesforce Mobile App Plus. On BYOD devices, MDM (Mobile Device Management) enforces: screen lock timeout (5 minutes), minimum OS version, remote wipe capability, and encrypted storage. The Mobile App Plus session persists for offline use; re-authentication is enforced by the Mobile App Plus ECA session policy (configured to require re-auth on a rolling window when connectivity returns, sized to the crew use case rather than a hard-coded 24 hours).

Integration Error Handling

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
Rights Management DB	Bidirectional sync via CDC	3 retries, exponential backoff (1s, 5s, 30s)	Anypoint MQ dead letter queue - failed rights syncs queued for manual review; dual-write discrepancy dashboard	Slack alert to integration lead + platform team channel on 3rd failure; daily discrepancy report to VP Licensing	Salesforce continues as primary; Rights DB updates queued. If Rights DB is down >4h during dual-write phase, pause dual-write and log all pending changes for replay
Content Management System	Scheduled daily pull + on-demand lookup	2 retries with 10s interval for on-demand lookups; daily batch auto-retries next cycle	Failed metadata records logged to custom Error_Log__c object in Salesforce	Email alert to CTO team if daily sync fails; individual lookup failures logged silently (stale metadata acceptable short-term)	Salesforce serves cached content metadata from last successful sync. Manual CMS lookup available as workaround
SAP ERP	Batch nightly + event-driven on deal close	Nightly batch: full retry next cycle. Deal-close event: 3 retries, exponential backoff (5s, 30s, 5min)	Anypoint MQ dead letter queue for failed financial postings; finance team notified immediately	PagerDuty alert to integration lead on deal-close failure; daily batch failure triggers email to CFO team	Revenue schedule creation paused. Licensing team manually flags deals needing SAP posting. Finance team reconciles during next successful batch run
Snowflake (via Data 360)	Zero-copy (no data movement)	N/A - Data 360 handles connection retries internally	N/A - no data transfer to fail	Data 360 connector health monitored via Setup > Data 360; alert to CTO if connection drops >1h	Churn scores and engagement segments show last-known values. Marketing journeys using stale segments continue with degraded targeting accuracy. No data loss risk (Snowflake data unaffected)
Streaming Platform	Inbound webhooks via Platform Events	MuleSoft retries webhook processing 3 times (1s, 10s, 60s); Platform Events have 72h replay window	Failed subscriber events stored in Anypoint MQ dead letter queue; replay available via Platform Event replay ID	Alert to consumer ops team if webhook processing failure rate exceeds 5% in any 1-hour window	Subscription records not updated in real-time. Batch reconciliation job runs every 6 hours to catch missed events from streaming platform’s event log
Payment Processor	Inbound webhooks	3 retries with exponential backoff (1s, 5s, 30s) at the Anypoint layer	Failed payment events in Anypoint MQ dead letter queue; critical (payment failures) escalated immediately	PagerDuty alert to consumer ops on any payment webhook failure; daily summary to VP Consumer	Subscription status not updated. Dunning flows delayed. Manual reconciliation from payment processor dashboard within 4 hours of outage resolution
Marketing Cloud	Marketing Cloud Connect	MC Connect handles retry internally; sync failures retry next cycle (15-min intervals)	MC Connect error log in Marketing Cloud; failed syncs visible in MC Connect dashboard	Weekly MC Connect health review by marketing ops; immediate alert if sync gap exceeds 4 hours	Journey triggers delayed. Active journeys continue with last-synced data. New subscribers not targeted until sync resumes
Ad Sales Platform	Scheduled daily batch	Full retry next cycle (daily)	Failed ad metric records logged to Error_Log__c	Email alert to Head of Ad Sales if daily pull fails 2 consecutive days	Content performance dashboards show stale ad metrics (clearly timestamped). No revenue impact - ad metrics are reporting-only

Reporting Domain Note

Reporting spans three business lines with distinct analytics needs: content ROI (production cost vs. licensing revenue + streaming performance), partner analytics (licensing revenue by partner with trend and renewal probability), and subscriber health (cohort analysis, engagement scores, churn by segment). Standard Salesforce reports with custom report types handle licensing, partner analytics, and a first-pass view of subscriber health by joining Subscription with the Data 360 engagement and churn fields enriched back onto the Subscription record. CRM Analytics is the incremental uplift for the consumer team’s deeper cross-dataset joins - blending subscription tenure, payment history, engagement trajectory, and content consumption trends with dataflow-level joins and self-service exploration - and is licensed for VP Consumer, CFO office, and the consumer analyst pool. Executive dashboards combine all three views. Data 360’s native segmentation feeds both operational automation (churn-triggered cases) and reporting (engagement score distributions) - avoid duplicating segment logic across reporting and automation layers.

Presentation Strategy

Go deep on two decisions: (1) Content rights data model with conflict detection - the defining domain challenge, (2) Snowflake/Data 360 integration for subscriber intelligence - demonstrates modern platform knowledge. Cover Marketing Cloud timing as a constraint-driven decision. Summarize remaining artifacts.

Scoring Rubric

Criterion	Weight	What Judges Look For
Data Architecture	25%	Content rights data model with conflict detection (the defining domain challenge). Subscriber data architecture with Data 360 and Snowflake zero-copy. High-volume analytics strategy. Content metadata model linking production to licensing to streaming
Integration Architecture	25%	Rights management DB integration. Streaming platform webhooks. Payment processing. SAP ERP for finance. Marketing Cloud Connect. Each endpoint classified with pattern, retry, DLQ, and monitoring
System Architecture	20%	Org strategy for dual business lines (B2B licensing + D2C streaming). Data 360 for subscriber intelligence and churn prediction. Marketing Cloud for engagement journeys. Licensing model across business units
Security & Compliance	15%	Content rights access controls. Subscriber data privacy (PII handling). B2B partner data isolation from D2C. Audit trail for licensing revenue. Data residency for global content distribution
Trade-offs & Communication	15%	WHY Data 360 + Snowflake over storing analytics in Salesforce. WHY content rights conflict detection matters (revenue protection). Marketing Cloud phasing justified by constraints. Clean diagrams showing dual business line architecture

---

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.