Case Study 5: ScreenVault Studios - Q&A Preparation

Work in Progress

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

Q&A Guide

This page compiles judge-style follow-up questions for the case study. Use it after your presentation run-through so you can test how well you defend your choices.

Q&A Snapshot

Field	Detail
Open after	Presentation Notes
Format	45-minute Q&A following a 45-minute presentation
Study role	Practice concise, defensible answers
Related pages	Case Study Overview, Scenario Paper, Worked Solution

Q&A Strategy

State your position, give the reasoning, acknowledge the trade-off, and keep answers to 1-2 minutes.

Q1: How does the rights conflict detection handle edge cases like partially overlapping windows or non-exclusive rights?

The Apex trigger queries existing active Content Right records matching the same Content Title and Territory with overlapping date ranges. For exclusive rights, any overlap is blocked. Non-exclusive rights do not conflict with each other. The trigger only fires when the proposed or existing right has Exclusivity = Exclusive. Partial window overlaps are caught by the date range comparison: existing.WindowStart < proposed.WindowEnd AND existing.WindowEnd > proposed.WindowStart.

Q2: 12,000 licensing contracts - what happens to performance when a rep searches available content across 50 territories?

The availability search queries Content Right records filtered by territory and date range, which is a well-indexed SOQL query. 12,000 contracts across 1,800 titles and ~50 territories means roughly 6-7 rights per title on average. Custom index on Content Title + Territory + Window End keeps query times under 1 second. If this scales significantly, a pre-computed availability cache (scheduled Apex recalculating nightly) replaces the real-time query.

Q3: Why custom objects for rights instead of Salesforce CPQ or Vlocity/Industries CPQ?

CPQ is designed for product configuration and pricing in a quote-to-cash flow. Content rights are fundamentally different. They are constraints on who can exploit intellectual property in specific geographies and time windows, not product line items. CPQ lacks native territory-window-exclusivity conflict detection. Building on CPQ would mean fighting the data model rather than extending it. Custom objects with purpose-built validation are simpler and more maintainable.

Q4: How do you handle a title that is in production but already has pre-sold licensing rights?

Content Title has a Status picklist (Development, Production, Post-Production, Released). Content Rights can be created against titles in any status - pre-sales are standard practice in media. The Production object links to the same Content Title, so licensing reps can see production status alongside active rights. A report shows titles with pre-sold rights and their production timelines, flagging any where production is behind schedule relative to rights window start dates.

Integration

Q5: Why MuleSoft Anypoint instead of Composer or native integrations? The volume seems moderate.

Volume alone (60K events/day) would not justify Anypoint. The decision is driven by capability requirements, not throughput. Three integration patterns in this scenario require Anypoint-level features: CDC-triggered bidirectional sync with the Rights DB where MuleSoft’s Salesforce CDC Connector subscribes to outbound Salesforce change events and MuleSoft polls or subscribes to a Rights DB event feed for inbound changes (Composer does not support CDC as a trigger), Anypoint MQ dead letter queues for failed SAP financial postings (Composer has no DLQ capability), and HMAC signature verification on inbound webhooks from the streaming platform and payment processor. Composer is a low-code tool designed for simple point-to-point flows with polling triggers. The Rights DB transition alone, with its dual-write phase and discrepancy monitoring, exceeds what Composer can manage. The highest-volume path (Snowflake at 50M events/day) bypasses middleware entirely via Data 360 (formerly Data Cloud) zero-copy, so Anypoint handles only the moderate-volume, high-complexity paths.

Q6: Data 360 zero-copy to Snowflake - what are the limitations?

Zero-copy provides read access, not write-back. Salesforce cannot push data into Snowflake this way. Latency depends on Snowflake query performance; complex aggregations may take seconds, not milliseconds. Calculated insights refresh on a schedule (hourly or daily), not real-time. For churn scoring, hourly refresh is sufficient. Every Calculated Insight execution queries Snowflake, so Snowflake warehouse compute cost is an ongoing operational expense owned by Finance in the program cost model. The trade-off is acceptable: we avoid ETL infrastructure entirely, and the scores are fresh enough for marketing and service use cases.

Q7: How do you handle the Rights DB transition if the developer leaves before month 4?

The integration layer is the insurance policy. By month 3, the bidirectional sync is operational and Salesforce has a complete copy of all rights data. The scenario requires a 30-day parallel operation window with daily discrepancy reporting, which runs from month 3 to month 4. On zero-discrepancy exit, Salesforce takes over as source of truth immediately. The Rights DB runs read-only from month 4 through month 9 as a reconciliation safety net and then decommissions. Knowledge transfer documentation happens in months 1-2 alongside the integration build: the Rights DB developer produces API reference documentation, a PostgreSQL schema snapshot, and data model mapping notes. If the developer leaves before month 3, the SI partner reverse-engineers the interface from the schema snapshot and test harness, using the Salesforce copy as the functional reference. Because write traffic to the Rights DB ends at month 4, the developer is no longer on the critical path after that point.

Q8: Subscriber webhooks from the streaming platform - how do you handle spikes like a viral show launch?

Platform Events are configured as high-volume Platform Events (checkbox in the event definition) and provide the ingestion layer with built-in queuing. Publish and delivery allocations for high-volume Platform Events are sized to the org’s edition and any add-on Event Allocation blocks, so the defensible number at board level is the program’s purchased allocation per 24-hour window, not a universal fixed limit. At 5,000 subscriber events per day on average, even a 10x spike (50K) is well within the allocation the program is sized for. Flow automation processes events asynchronously with CPU-safe subscribers. Back-pressure is owned by MuleSoft Anypoint MQ, not the upstream streaming platform: the webhook endpoint acknowledges the streaming platform immediately, the payload lands in Anypoint MQ, and Mule flows drain the queue into Platform Events at a rate the subscribers can tolerate. That pattern keeps us independent of how well the streaming platform’s retry mechanism behaves.

Q9: Content Title is Public Read Only - does that expose sensitive information?

No. Content Title holds catalog metadata: title name, genre, cast, production status. All financial data lives on Content Right (Controlled by Parent, inherits Private from Account) and Opportunity (Private OWD). A marketing specialist can see that a documentary exists and its genre but cannot see what Netflix pays for it. Field-Level Security on Content Right’s LicenseFee and payment term fields provides a second layer restricted to Licensing and Finance profiles.

Q10: How do you prevent a licensing rep from seeing subscriber data, and vice versa?

Role hierarchy separation. Licensing and Consumer teams are in different branches with no cross-branch visibility. Account OWD is Private, so a licensing rep owns Licensing Partner accounts and sees nothing about Subscriber accounts. The consumer team owns Subscriber accounts and cannot see licensing deals. Content Title (Public Read Only) is the only shared data - intentionally, because both teams need catalog awareness. No sharing rules cross the boundary.

Subscriber records flagged with DataResidencyRegion = EMEA are subject to GDPR. Right-to-erasure requests trigger a Privacy Center policy (not a custom Flow alone) because Privacy Center knows how to purge AccountHistory, FieldHistoryArchive, and Field Audit Trail history rows along with the current-state PII. A Flow-only anonymization leaves the original PII in history tables, which is a GDPR violation. The Privacy Center policy cascades: current-state PII on Account, Subscription, and Cases is cleared or replaced with hashed tokens; history rows for those fields are deleted; and related records referenced by the subject profile are either anonymized or deleted depending on the data class. Marketing Cloud deletions are orchestrated through the Marketing Cloud Contact Delete API rather than suppression lists alone, because suppression prevents re-contact but does not delete the contact record. Data 360 profile data is removed via a targeted Data 360 delete job so that identity-resolved profiles lose the PII linkage while aggregate engagement trends retain only hashed tokens. End-to-end reconciliation evidence is captured in a DSR audit log that records every downstream system confirmation before the request is marked complete.

Marketing

Q12: Marketing Cloud live at month 5 with basic segmentation - won’t that hurt subscriber retention compared to Mailchimp?

Month 5 Marketing Cloud delivers the same campaign types Mailchimp runs today: welcome series, re-engagement, winback. The segmentation is initially demographic (subscription tier, signup date, region) - same as current Mailchimp. No regression. Once Data 360 connects at month 7, behavioral segments (viewing patterns, churn scores) upgrade targeting significantly. The trade-off is 2 months of equivalent-to-Mailchimp performance before the uplift arrives. Automations and Content Builder templates are rebuilt manually in Journey Builder during months 2-4 because no automated translator converts Mailchimp logic into Journey Builder canvases - that manual rebuild is explicitly funded in the program plan.

Q13: B2B and B2C in the same Marketing Cloud instance - how do you prevent cross-contamination?

Separate Business Units within Marketing Cloud. B2B Business Unit manages partner communications (content announcements, licensing promotions). B2C Business Unit manages subscriber journeys. Each has independent sender profiles, suppression lists, and consent tracking. Data extensions are scoped to business units. A partner contact never receives a subscriber winback email, and a subscriber never receives a licensing announcement.

Mobile & Production

Q14: Offline sync for 200 crew members - what technology specifically?

Salesforce Mobile App Plus with Briefcase Builder. Briefcase Builder runs on Mobile App Plus (not the base Salesforce Mobile App), which adds a per-user license cost for the 200 crew that must be carried in the program budget. Briefcases define which records sync offline per user: their assigned Production, related Crew Assignments, Equipment records, and Contact records for talent and vendors. Briefcase Builder is record-data only - it does not sync ContentDocument, ContentVersion, or Attachments. For offline documents like permits and call sheets, crews pre-download PDFs into a managed document cache on the device while on Wi-Fi; permit files are staged as static assets rather than as Salesforce Files. Offline edits (equipment check-in/out, schedule updates, location check-ins) sync when connectivity returns with conflict resolution favoring the latest timestamp. Briefcase Builder’s offline budget is record-count based at up to 50,000 records per user across all active briefcases (not a data volume limit), so crew briefcases are scoped to the active production and a rolling window of prior productions. Rejected Field Service Mobile because there is no dispatch or work order workflow in production crews (they are project-based, not service-based) and the per-user license adds cost without corresponding capability gain above Mobile App Plus with Briefcase Builder.

Q15: BYOD for production crews creates security risk. How do you mitigate?

Three layers. First, MDM (Mobile Device Management) enrollment is required before Salesforce Mobile App Plus installation - enforces screen lock, OS version minimums, and enables remote wipe. Second, the Salesforce Mobile App Plus External Client App restricts access to managed devices only via device-based session policies (configured on the ECA, or on any existing Connected App still serving pre-Spring ‘26 integrations). Third, Briefcase limits offline data to production-specific records - a crew member’s device never contains licensing deal terms or subscriber PII. If a device is lost, MDM remote wipe removes the Salesforce container without affecting personal data.

Large Data Volumes & Performance

Q16: 2M subscriber records in Salesforce. What are the LDV implications and how do you prevent performance degradation?

2M records is at the lower end of LDV concern but crosses the threshold where query performance matters. Three measures. First, custom indexes on Subscription fields used in SOQL WHERE clauses: Account, Status, Tier, and ChurnScore. Indexes are self-service and sufficient at this volume - Skinny Tables are not warranted here because Skinny Tables are a Salesforce Support request reserved for objects typically at 5M+ records where custom indexes and query shaping have already been exhausted. If the active Subscription volume grows past 5M, Skinny Tables become a next-step option to request through Support. Second, selective SOQL patterns in Apex and reports: WHERE clauses always include an indexed field, LIMIT is enforced on list views, and the rights conflict pattern of bounded-date-range queries is reused for subscriber list rebuilds. Third, archival strategy for cancelled subscribers older than 24 months. They are offloaded to Snowflake (already part of the architecture) through the MuleSoft pipeline for historical analytics access without polluting active record queries. Big Objects are rejected here because 2M-4M records are not LDV by the Big Object threshold and Big Objects cannot be freely joined with standard objects in reports, which would break the cross-object subscriber health dashboards. Data 360 handles the truly high-volume data (50M streaming events/day) outside Salesforce entirely.

Q17: What happens when the Rights DB integration fails mid-dual-write? How do you prevent data divergence?

The dual-write phase is the highest-risk period for data integrity. Three safeguards. First, every CDC event that triggers a Rights DB update is logged with a correlation ID. If the Anypoint flow fails after the Salesforce write succeeds, the event goes to the Anypoint MQ dead letter queue with full payload and error context. Second, a daily discrepancy dashboard compares record counts and checksums between Salesforce Content Right records and Rights DB entries. The integration lead reviews this dashboard every morning during the dual-write phase. Third, if the Rights DB is down for more than 4 hours during dual-write, the runbook prescribes pausing dual-write entirely: Salesforce continues as the working system, and all pending changes are queued for replay when the Rights DB recovers. The 30-day zero-discrepancy exit criterion ensures we do not switch Salesforce to source of truth until the process is proven reliable.

Q18: How do you validate 12,000 migrated rights contracts? What if the legacy data already contains conflicts?

Migration validation runs in three passes. First pass: schema validation confirms every record has required fields (Content Title, Account, Territory, Window Start, Window End, Exclusivity). Second pass: referential integrity confirms every Content Title ID and Account ID maps to a valid Salesforce record. Third pass: the same Apex conflict detection logic that protects live data runs against all imported active rights. If pre-existing conflicts are found in the legacy data (likely, given it was managed via spreadsheets), they go into a conflict resolution queue for the VP Content Licensing to review. Each conflict gets a record with both sides of the overlap and a recommended resolution (shorten one window, change exclusivity, or flag as grandfathered). No go-live until the conflict queue is empty.

Governance & Dev Lifecycle

Q19: Three concurrent workstreams with overlapping phases. How do you prevent merge conflicts and release collisions?

Branch strategy is the first defense. Each workstream develops on feature branches merging to a shared develop branch. Release branches (release/phase-1, release/phase-2, release/phase-3) cut from develop at sprint boundaries. The key rule: no direct commits to develop or release branches. Everything goes through pull requests with required code review from the CoE lead or a designated platform team member. For metadata conflicts (two teams modifying the same object), the partial copy integration sandbox is the detection point. Both teams deploy to it bi-weekly, and any metadata collision surfaces there before reaching UAT. The Technical Review Board (bi-weekly) reviews cross-team dependencies and sequences deployments to avoid same-day production pushes from different workstreams.

Q20: The SI partner leaves after 14 months. How does the internal team maintain the platform?

The transition plan has three parts. First, the CoE is established at month 3, not month 14. The internal admin becomes full-time platform owner, attending every SI design session and code review from the start. Second, the SI partner provides 20 hours/month of managed services for 6 months post-program. This covers production support, complex bug fixes, and architectural guidance. Third, knowledge transfer is explicit: months 12-14 include documented handoffs for every integration (Anypoint flows, Data 360 configuration, Marketing Cloud journey architecture) with the internal developer shadowing the SI team. The 85% Apex test coverage requirement also helps: well-tested code is maintainable code. If the internal team cannot resolve an issue during the managed services period, that becomes evidence for extending the retainer or hiring additional Salesforce talent.

Q21: What gets cut if Phase 1 runs over? How do you protect the Mailchimp deadline?

Phase 1 (licensing) and the Mailchimp deadline are on different critical paths. Marketing Cloud provisioning starts at month 4, independent of licensing work. Even if the Rights DB integration is behind schedule, the Marketing Cloud track has its own team (marketing ops + SI resources dedicated to MC). The buffer is in Phase 3: production mobile and analytics are lowest priority and can absorb 2-3 months of schedule pressure. If Phase 1 slips by more than 2 months, the specific trade-off is delaying the partner portal (Experience Cloud), which is the least revenue-critical Phase 1 deliverable. Content ROI dashboards in Phase 3 depend on Phase 1 licensing data, so they shift proportionally but do not block any other workstream.

Org Strategy & Architecture

Q22: Why a single org for three very different business lines? When would you reconsider?

Single org because the three business lines share a common asset: the content library. Content Title is the connective tissue. Licensing reps need to see production status when pitching. Production managers need to see which titles have pre-sold rights. Subscriber churn analytics inform content acquisition decisions. A multi-org approach would require cross-org data sync for Content Title, duplicating the single most important dataset. The role hierarchy and OWD model provide clean data isolation where needed (licensing deal terms invisible to subscriber team, subscriber PII invisible to licensing). Reconsider single org if: SVS acquires a company with its own Salesforce instance (evaluate merge vs. connect), a new business line has regulatory isolation requirements (e.g., healthcare content requiring HIPAA-separate data), or the total user count exceeds 5,000 and org complexity creates admin bottleneck.

CRM Analytics is the pragmatic choice rather than the only option. Standard Salesforce reports with custom report types can cover most subscriber health views now that Data 360 enrichment writes churn probability and engagement score back onto the Subscription record, and a custom report type spanning Subscription, Content Performance, and the activated Data 360 fields is a legitimate first pass. CRM Analytics is justified as the incremental uplift for the cross-object, multi-dataset joins the consumer team needs on an ongoing basis: blending subscription tenure, payment history, engagement trajectory, and content consumption trends with dataflow-level joins that standard reports cannot match, plus self-service exploration for the VP Consumer and CFO without developer turnaround. The license line for the analyst pool (VP Consumer, CFO office, and about ten analysts) is modeled in the program cost plan. The alternative is building custom LWC dashboards with Apex controllers, which trades license cost for development time and maintenance burden, and loses the self-service modification capability the business team values.

Identity & SSO

Q24: 2M subscribers but only 5-10% use the self-service portal. How do you manage identity for that subset without over-provisioning?

Experience Cloud users must be backed by either a Contact on an Account or a Person Account - there is no login model against a standalone Account record. Two architecturally valid options for SVS. Option A: enable Person Accounts for the Subscriber record type so each of the 2M subscriber identities is a single record that can carry an Experience Cloud user when one is provisioned. Person Account enablement is irreversible and has org-wide effects, so this is a CEO-level decision made up front in the program. Option B: model subscribers as Contact records under a single system-owned “ScreenVault Subscribers” Account, which keeps Person Accounts disabled but makes cross-object reporting slightly harder and forces the integration layer to maintain the Contact-to-streaming-platform mapping. The solution picks Option A because it keeps the subscriber identity a first-class record and makes Case, Marketing Cloud, and Data 360 identity resolution cleaner. 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, not named users). That cost is in the program run-rate budget at roughly $6 per login per month, or $7.2M-$14.4M per year at full adoption, which is flagged as the dominant long-term operating cost of the consumer platform and is cited as a reason the portal is opt-in rather than mandatory. The streaming platform remains the primary identity provider for the streaming app itself; Salesforce only owns identity for the support/billing portal.

The workflow is orchestrated through Salesforce Privacy Center, not a standalone Flow, because Privacy Center policies know how to cascade through both current-state data and history tables. A subscriber request is flagged in Service Cloud, which opens a Data Subject Request (DSR) case and triggers the linked Privacy Center policy. Step one: Marketing Cloud deletion runs via the Marketing Cloud Contact Delete API (not just suppression) so the contact record and its data extensions are removed, not just muted. A suppression list is also added as a short-term safety net while the delete job runs. Step two: the Privacy Center policy anonymizes or clears current PII on the Salesforce Account and related records (Subscription, Cases, anonymized via hashed tokens, email/phone cleared). Critically, the same policy also purges AccountHistory, FieldHistoryArchive, and Field Audit Trail rows for the tracked PII fields so no original values survive in history tables. Step three: Data 360 is instructed to remove the PII linkage from the identity-resolved profile and to delete the underlying profile data via a Data 360 delete job; anonymized aggregate engagement trends stay, PII-linked rows do not. Step four: the orchestration calls deterministic delete or anonymization endpoints on every remaining connected system - Rights DB (only during the 30-day parallel-run phase), CMS for talent contacts if any, and SAP for customer master records - and records each downstream confirmation in the DSR audit log. The audit log is the evidence of compliance, maintained on an immutable object. Target: completion within 72 hours of request, well within the GDPR 30-day requirement.

Content Right is a master-detail junction with two parents: Account (Licensing Partner) as the primary master and Content Title as the secondary master. Primary matters because the record owner inherits from the primary parent - Content Right owner is the Account owner - and because the Experience Cloud partner portal sharing story hangs on that choice. With Account as primary, partner users in Experience Cloud see only the Content Right children of their own Account through record ownership; no additional sharing set is required, and no other partner’s rights are ever visible. The two master-detail sharing settings are configured distinctly: Account master-detail sharing is “Read/Write” (the rep must have Read/Write on the partner Account to create or edit rights, which they do because they own that Account), and Content Title master-detail sharing is “Read” (the rep needs only Read on Content Title, which is satisfied by Content Title’s Public Read Only OWD). So a licensing rep with Read/Write on their partner Account and Read on the catalog can create Content Right records without ever needing Edit on Content Title. If we had put Content Title as the primary master instead, Content Right would inherit Public Read Only from Content Title and every partner would see every other partner’s deal - a catastrophic data leak we explicitly rejected. The Opportunity relationship is a lookup, not a master-detail, because Content Right can exist without an open Opportunity (renewals, amendments, manual grants) and cascade-delete from Opportunity would destroy active rights.

Q27: You enabled Person Accounts for 2M subscribers - how do you defend that decision and what are the cost and reversibility implications?

Person Accounts are irreversible and org-wide, so this is a CEO-level architecture decision taken at program kickoff, not a mid-program tweak. I defend it on three grounds. First, structural correctness: Experience Cloud users must be backed by either a Contact under an Account or a Person Account, and a Contact-under-global-Account model for 2M subscribers creates report-blind spots (cross-object joins on a single synthetic Account distort metrics) and forces the integration layer to maintain a Contact-to-streaming-platform mapping outside the subscriber record. Person Accounts make each subscriber a first-class record and carry clean identity into Marketing Cloud and Data 360 identity resolution. Second, scale envelope: 2M Person Accounts is inside standard Salesforce scale with appropriate indexes; it is not an LDV risk at this volume. Third, cost control: only the 100K-200K subscribers who actually register for the self-service portal are provisioned with Customer Community Plus Login licenses. Login licenses are metered by login events rather than by named users, which keeps consumer-platform license cost proportional to real portal activity. At roughly $6 per login per month, full adoption of 200K active portal logins lands in the $7.2M-$14.4M per year range, and that is flagged in the cost model as the dominant long-term operating expense of the consumer business line; it is explicitly the reason the portal is opt-in. The irreversibility trade-off is accepted because we do not foresee a scenario where we would want to unmake the B2C subscriber identity model, and the alternative (disabled Person Accounts + synthetic global subscriber Account with 2M Contacts) is strictly worse for reporting, Data 360 identity resolution, and day-to-day data model clarity.

Question Categorization

Domain	Questions
D1 System Architecture	Q14, Q22, Q23, Q27
D2 Security	Q9, Q10, Q11, Q15, Q24, Q25, Q26
D3 Data	Q1, Q2, Q3, Q4, Q16, Q18
D4 Solution Architecture	Q12, Q13, Q21
D5 Integration	Q5, Q6, Q7, Q8, Q17
D6 Dev Lifecycle	Q19, Q20
D7 Communication	(covered in presentation delivery)

Q&A Survival Rules

Answer the question asked. Do not pivot to a topic you prepared better for.
State position first, then reasoning: “I chose X because Y. I rejected Z because W.”
Name the trade-off proactively. Judges respect honesty over pretending there is no cost.
Say “I don’t know” when appropriate: “I would validate that during the design phase”
Stay within 1-2 minutes per answer

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.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.