Live CTA Scenario Solves — Mega Print and GRC

Part 115: Live CTA Scenario Solves — Mega Print and GRC

If you’ve been following this architecture series, you’ve absorbed a lot of theory — org strategy, data modeling, integration patterns, security models, governance frameworks. All of that matters. But the CTA board review is where theory meets reality. You walk into a room (or a virtual session), receive a scenario you’ve never seen before, and have to design a complete enterprise architecture on the spot while three judges probe every decision you make.

The best way to prepare for that? Practice with well-known scenarios until the process of decomposing a business problem into an architecture becomes second nature.

In this post, I’m walking through two classic CTA practice scenarios: Mega Print and Greenhouse Recycling Corporation (GRC). I’ll break down how I’d approach each one — the org strategy, the data model, the integration architecture, the security model, and the diagrams I’d draw. Then I’ll hit you with the kinds of questions judges actually ask and how to handle them without breaking a sweat.

Solving Mega Print

Scenario Overview

Mega Print is one of the most well-known CTA practice scenarios in the community. Here’s the setup:

Mega Print is a large commercial printing company with multiple business units — think large-format printing, packaging, direct mail, and digital services. Each business unit operates semi-independently with its own sales teams, pricing models, and fulfillment workflows. The company has grown through acquisitions, so there’s a patchwork of legacy systems — an on-premise ERP for financials, a homegrown order management system, and various department-level tools that don’t talk to each other.

The key business requirements typically include:

Unified customer view across all business units (customers often buy from multiple divisions)
B2B Commerce for self-service ordering, especially for repeat customers with negotiated pricing
Complex quoting and pricing — different business units have wildly different pricing structures (per unit, per square foot, tiered volume discounts, contract pricing)
Integration with the existing ERP for financials and inventory
Reporting and analytics that span the entire enterprise, not just individual business units
Scalability — Mega Print is growing and plans more acquisitions

This is a scenario that tests your ability to handle multi-business-unit complexity without over-engineering the solution.

Solution Approach

Org Strategy

The first question the judges want answered: single org or multi-org?

For Mega Print, I’d recommend a single org strategy. Here’s why:

The business units share customers, so a unified Account and Contact model is critical. A multi-org approach would force you into cross-org data synchronization, which adds latency, complexity, and data quality risk.
Salesforce’s multi-tenant architecture handles business unit separation elegantly through record types, permission sets, and sharing rules — you don’t need separate orgs for logical separation.
A single org makes enterprise reporting straightforward. Cross-org reporting is painful and requires either an ETL layer or Salesforce Connect, both of which add cost and complexity.

The caveat I’d call out: if an acquired company runs on a completely different CRM with deeply embedded customizations, I might recommend a phased migration approach — keep the acquired org temporarily while building out the unified model, then migrate in waves. But the target state is always single org.

Data Model

This is where Mega Print gets interesting. The data model needs to handle:

Accounts and Contacts — Standard Account hierarchy to represent the parent company and its subsidiaries. I’d use Account record types to distinguish between prospects, customers, and partners. Contact roles become important here to track who the buyer is versus the accounts payable contact versus the production contact.
Products and Pricing — This is the hardest part. Each business unit has different product catalogs and pricing structures. I’d use multiple price books (one per business unit, plus a standard price book as the baseline). For complex pricing logic that goes beyond what CPQ handles natively — like square footage calculations or substrate-based pricing — I’d build custom pricing engine logic in Apex that integrates with the quoting process.
Opportunities and Quotes — Standard Opportunity model with a record type per business unit. Salesforce CPQ (or Revenue Cloud) for quote generation, with custom quote line editor configurations per business unit. I’d push for CPQ over a custom quoting solution because it gives you approval workflows, guided selling, and document generation out of the box.
Orders and Fulfillment — Orders in Salesforce map to the order management process, but fulfillment tracking stays in the legacy system. The Order object in Salesforce serves as the handoff point — once an order is approved and synced to the ERP/OMS, Salesforce tracks status updates via integration callbacks.

Integration Architecture

Mega Print’s integration landscape is where you demonstrate your technical depth. Here’s how I’d lay it out:

Salesforce to ERP (Financials/Inventory) — Middleware-based integration using MuleSoft or an equivalent iPaaS. The ERP is the system of record for financials and inventory. Salesforce pushes approved orders to the ERP via an asynchronous API call. Inventory availability checks from Salesforce are synchronous callouts to the middleware layer, which queries the ERP in real time. I’d recommend a canonical data model in the middleware to decouple Salesforce’s data structure from the ERP’s.
Salesforce to Order Management System — Similar pattern. Order creation is an outbound event from Salesforce. Order status updates flow back into Salesforce via a webhook or polling mechanism. I’d use Platform Events on the Salesforce side to handle inbound status updates asynchronously.
B2B Commerce to Salesforce Core — B2B Commerce (formerly CloudCraze, now native) runs on the same org, so this isn’t really an “integration” — it’s configuration. Product catalogs, pricing, and account data are shared. The key design decision is how to handle guest user access versus authenticated buyer access and how to structure the buyer account hierarchy so that procurement managers only see their company’s negotiated prices.
Data Migration — Don’t forget to address this. Mega Print has years of historical data in legacy systems. I’d recommend migrating only active customer records and open orders into Salesforce, with historical data accessible via a read-only integration to the legacy system (or a data warehouse). Full historical migration is almost never worth the cost and risk.

Security Model

The security model for Mega Print revolves around business unit isolation with controlled cross-visibility:

Role Hierarchy — Mirrors the organizational structure. Each business unit has its own branch in the hierarchy. Regional managers sit above account executives. A VP of Sales sits at the top and sees everything.
Sharing Rules — Criteria-based sharing rules to give cross-business-unit visibility where needed. For example, if a customer buys from both Large Format and Packaging, both teams need to see the shared Account but should only see their own Opportunities.
Permission Sets and Permission Set Groups — One base permission set per business unit role, with additional permission sets for specialized access (e.g., CPQ admin access, B2B Commerce storefront management). I’d avoid relying on profiles for anything beyond the minimum — permission sets are the future.
Field-Level Security — Sensitive fields like margin percentage or cost data should be visible only to finance roles and senior leadership, not to all sales reps.

Key Diagrams for Mega Print

When you’re at the board, you need to draw diagrams that tell the story efficiently. For Mega Print, I’d prepare:

System Landscape Diagram — Shows Salesforce at the center with all integrated systems (ERP, OMS, B2B Commerce, Data Warehouse). Arrows indicate data flow direction and integration pattern (sync vs. async, middleware vs. direct). This is the first diagram judges look at to understand your big-picture thinking.
Data Model Diagram (ERD) — Focus on the key objects: Account, Contact, Opportunity, Quote, Quote Line, Order, Order Product, Product, Price Book Entry. Show the relationships and call out where you’re using standard versus custom objects. Don’t try to draw every field — just the structural relationships.
Integration Sequence Diagram — Pick the most complex integration flow (order creation from Salesforce through middleware to ERP) and draw a sequence diagram showing the request/response pattern, error handling, and retry logic. This shows judges you understand the details, not just the boxes-and-arrows level.
Security Model Diagram — A simplified role hierarchy tree with annotations showing where sharing rules kick in and what each level can access. Judges love to poke at security, so having this visual ready saves you time.

Mega Print Q&A — Common Judge Questions

“Why a single org instead of multi-org? What if the acquired company has 500 custom objects?”

Strong answer: Acknowledge the complexity. Explain that a single org is the target state for data consistency and reporting, but the migration is phased. In the interim, you might use Salesforce Connect to expose critical data across orgs while the migration proceeds. The 500-custom-object situation is a data modeling exercise — many of those objects likely duplicate functionality that exists in standard Salesforce objects or can be consolidated.

“How do you handle pricing when each business unit has fundamentally different pricing models?”

Strong answer: Multiple price books handle the catalog separation. For complex pricing logic (dynamic calculations, conditional discounts), I’d extend CPQ with custom pricing plugins or Apex-based pricing methods. The key principle is keeping the pricing engine centralized so that cross-business-unit bundles are possible in the future, even if they’re not required today.

“What happens when the ERP is down and a sales rep needs to submit an order?”

Strong answer: The integration architecture uses an asynchronous pattern with guaranteed delivery. Orders are queued in the middleware layer. Salesforce marks the order as “Pending Sync” and the rep can continue working. When the ERP comes back online, the queue drains automatically. I’d also recommend a monitoring dashboard that alerts the integration team when the queue depth exceeds a threshold.

“How do you ensure data quality when multiple business units are creating accounts?”

Strong answer: Duplicate management rules in Salesforce catch obvious duplicates at the point of entry. Beyond that, I’d implement a master data management (MDM) process — either using Salesforce’s native duplicate matching or an external MDM tool — that runs periodic deduplication sweeps. Account ownership follows a defined governance model: the business unit with the largest revenue relationship “owns” the account, but all business units have visibility.

“Walk me through the B2B Commerce buyer experience.”

Strong answer: Authenticated buyers log in and see a storefront filtered to their business unit’s product catalog with their negotiated pricing. They can browse, add to cart, and submit orders that flow directly into Salesforce as Order records. The storefront respects the account hierarchy — a procurement manager at a parent company can order on behalf of subsidiaries. Guest users see a marketing-focused catalog without pricing and are directed to a “Request a Quote” flow that creates a Lead in Salesforce.

Solving Greenhouse Recycling Corporation (GRC)

Scenario Overview

GRC is another classic CTA practice scenario, but it tests a very different set of skills than Mega Print. Here’s the setup:

Greenhouse Recycling Corporation is a waste management and recycling company that operates across multiple regions. They provide residential and commercial waste collection, recycling processing, and hazardous waste disposal. The company is modernizing its operations and wants Salesforce to be the backbone of its digital transformation.

The key business requirements typically include:

Field Service operations — Thousands of trucks and field technicians handling pickups, equipment maintenance, and hazardous waste disposal on daily routes
IoT integration — Smart bins and containers with sensors that report fill levels, enabling dynamic route optimization
Compliance and regulatory tracking — Hazardous waste disposal requires chain-of-custody documentation, EPA compliance, and audit trails
Customer self-service portal — Residential and commercial customers need to schedule pickups, report missed collections, and manage their accounts
Contract management — Long-term service agreements with municipalities and commercial clients, often with SLA requirements and penalty clauses

This scenario tests your ability to handle Field Service Lightning, IoT, compliance requirements, and operational scale.

Solution Approach

Org Strategy

Again, single org is the right call here. GRC’s operations are unified — field service, customer management, compliance, and billing all need to reference the same customer and service data. There’s no business case for splitting this across orgs.

The one nuance: if GRC operates in regions with strict data residency requirements (e.g., Canadian customer data must stay in Canada), you need to address this. Salesforce’s data residency options (like Hyperforce) can handle regional data requirements within a single org. If the requirements are extreme, you might need a secondary org for that region with Salesforce Connect bridging the gap — but that’s a last resort.

Field Service Architecture

This is the centerpiece of the GRC solution. Here’s how I’d architect it:

Service Territories — Define territories by geographic region. Each territory maps to a depot or operations center. Service territory members are the field technicians and truck drivers assigned to that region.
Work Orders and Service Appointments — Every pickup, maintenance visit, and hazardous waste disposal is a Work Order. Service Appointments represent the scheduled time slots. For routine pickups, I’d use recurring Work Orders that auto-generate based on the customer’s service schedule.
Scheduling and Route Optimization — Salesforce Field Service’s scheduling engine handles appointment booking, but for route optimization across hundreds of daily stops, I’d integrate with a specialized routing engine (like Google Route Optimization API or a dedicated fleet management tool). The routing engine receives the day’s appointments and returns optimized sequences. Those sequences are pushed back into Salesforce as the technician’s daily plan.
Mobile Experience — Field technicians use the Salesforce Field Service mobile app to receive their daily assignments, navigate to locations, capture service completion (photos, signatures, weight readings), and flag issues. Offline capability is critical — technicians often work in areas with poor connectivity. I’d configure the mobile app’s offline priming to pre-download the day’s Work Orders and related records.
Dispatcher Console — Dispatchers use the Field Service Dispatcher Console to monitor real-time operations, handle emergency pickups, reassign work when a truck breaks down, and track SLA compliance.

IoT Integration

Smart bins with fill-level sensors add a layer of complexity:

IoT Data Ingestion — Sensor data flows into Salesforce via Platform Events or through an IoT hub (like AWS IoT Core or Azure IoT Hub) that acts as an intermediary. I would not recommend sending raw sensor telemetry directly to Salesforce — it would eat through API limits and storage. Instead, the IoT hub aggregates sensor readings and sends meaningful events to Salesforce (e.g., “Bin 4523 is at 85% capacity”).
Orchestration Rules — When Salesforce receives a “bin nearly full” event, an automation (Flow or Platform Event trigger) creates or updates a Work Order for that location. If the bin is on an existing route, the priority gets bumped. If it’s not on any route, an emergency pickup request goes to the dispatcher.
Asset Management — Every smart bin is an Asset record in Salesforce, linked to the customer Account and the Service Location. Asset records track the sensor hardware version, last maintenance date, battery level, and firmware version. This becomes important for maintenance scheduling — you don’t want a sensor to die in the field without a replacement plan.

Compliance Considerations

Hazardous waste compliance is non-negotiable and a key differentiator in your GRC presentation:

Chain of Custody — Every hazardous waste pickup must be documented from collection through transport to final disposal. I’d model this as a custom Chain of Custody object linked to the Work Order, with status stages (Collected, In Transit, Received at Facility, Processed, Disposed). Each stage transition requires a digital signature captured on the mobile app.
Regulatory Reporting — EPA and state agencies require periodic reports on hazardous waste volumes, disposal methods, and any incidents. I’d build a reporting data model that aggregates Work Order completion data, chain of custody records, and incident reports into a format that maps to regulatory filing requirements. This likely means a custom report type or a scheduled Apex job that generates the report data.
Audit Trail — Field-level audit trails on all compliance-related objects. Salesforce’s standard field history tracking covers most needs, but for objects where you need more than 20 tracked fields, I’d implement a custom audit log using Platform Events and a Big Object for long-term storage.
Certifications and Training — Field technicians handling hazardous waste need specific certifications. I’d track certifications on the Service Resource record and build validation logic that prevents dispatchers from assigning hazardous waste Work Orders to uncertified technicians.

Key Diagrams for GRC

System Landscape Diagram — Salesforce (Sales Cloud, Service Cloud, Field Service, Experience Cloud) at the center, with integrations to the IoT hub, routing engine, ERP (for billing), and regulatory reporting systems. Show the data flow clearly — IoT data comes in, Work Orders go out to the mobile app, billing data goes to the ERP.
Field Service Process Flow — A swimlane diagram showing the end-to-end flow: customer requests service (or IoT triggers a pickup) through dispatching, field execution, completion, and billing. Swimlanes for Customer, Dispatcher, Field Technician, and Back Office. This diagram tells the operational story better than anything else.
IoT Event Architecture Diagram — Shows the path from sensor to action: Sensor sends data to IoT Hub, IoT Hub aggregates and filters, meaningful events publish to Salesforce Platform Events, automation creates or updates Work Orders. Include the data volumes and frequency to show you’ve thought about scale.
Compliance Data Model Diagram — An ERD focused on the compliance objects: Work Order, Chain of Custody, Incident Report, Certification, Regulatory Filing. Show the relationships and the key fields on each object. Judges will test whether your compliance model actually works for real-world regulatory requirements.

GRC Q&A — Common Judge Questions

“How do you handle the volume of IoT data without hitting Salesforce limits?”

Strong answer: Raw telemetry never touches Salesforce. The IoT hub handles data ingestion at scale — it can process millions of sensor readings per hour. Only actionable events are forwarded to Salesforce as Platform Events. I’d set thresholds in the IoT hub (e.g., only send an event when a bin crosses 80% capacity, and don’t send again until it’s been emptied and refills). This reduces the Salesforce event volume to hundreds or low thousands per day, well within platform limits.

“What happens when a field technician is in an area with no cell coverage?”

Strong answer: The Field Service mobile app supports full offline mode. Technicians’ daily Work Orders and related data are pre-downloaded during morning briefing at the depot (where connectivity is reliable). Technicians complete their work offline — recording completion, capturing signatures, taking photos. When they return to a coverage area or the depot, the app syncs automatically. Conflict resolution follows a “last write wins” policy for most fields, with dispatcher review for any conflicts on critical fields like hazardous waste quantities.

“How do you prevent an uncertified technician from being dispatched to a hazardous waste job?”

Strong answer: Two layers of protection. First, the Field Service scheduling engine uses work rules and service resource skills — hazardous waste Work Orders require a specific skill that only certified technicians have. The scheduler simply won’t assign the job to someone without the skill. Second, as a backstop, a validation rule on the Service Appointment prevents manual override by dispatchers unless the assigned resource has the required certification. If no certified technician is available, the system escalates to a supervisor rather than assigning an uncertified person.

“How do you handle SLA tracking for municipal contracts?”

Strong answer: Each municipal contract is modeled as an Entitlement in Salesforce with associated Milestones. For example, a milestone might be “Respond to missed collection report within 4 hours” or “Complete 98% of scheduled pickups within the contracted time window.” Entitlement processes auto-track milestone completion against the Work Order timestamps. I’d build a dashboard that shows SLA compliance by contract, by territory, and by time period — giving operations leadership a real-time view of where they’re meeting commitments and where they’re at risk.

“Walk me through what happens when a smart bin sensor fails.”

Strong answer: The IoT hub monitors heartbeat signals from each sensor. If a sensor stops reporting for longer than its expected interval (e.g., no reading in 24 hours), the hub fires a “sensor offline” event to Salesforce. This creates a maintenance Work Order on the Asset record for the bin. The Work Order is assigned to a maintenance technician, not a collection driver — different skill set. Meanwhile, the bin reverts to its static collection schedule so pickups continue uninterrupted. The dispatcher sees a flag on the route indicating the bin is on manual schedule until the sensor is repaired.

Section Notes — General Scenario-Solving Tips

After working through dozens of these scenarios, here are the principles that separate candidates who pass from those who don’t:

Start with the business, not the technology. When you first read the scenario, resist the urge to jump to “I’ll use Platform Events” or “We need MuleSoft.” Instead, ask yourself: what is this company trying to achieve? What are their biggest pain points? What does success look like for them? Your architecture should be a response to business needs, and every technical decision should trace back to a business requirement.

State your assumptions explicitly. The scenario will have ambiguities — that’s by design. Don’t ignore them. Call them out. Say “I’m assuming that the ERP is the system of record for billing, and here’s how that affects my integration design.” Judges want to see that you can identify gaps in requirements and make reasonable assumptions rather than pretending everything is clear.

Don’t boil the ocean. You have limited time. You cannot design every detail of a complete enterprise architecture in 45 minutes. Prioritize the areas that matter most for the scenario. For Mega Print, that’s the multi-business-unit data model and pricing. For GRC, that’s Field Service and compliance. Spend your time where it counts and acknowledge that other areas would need further discovery.

Your diagrams are your presentation. The judges are looking at your whiteboard, not reading a document. Draw clear, labeled diagrams. Use consistent notation. Make sure your system landscape diagram is the anchor — everything else should reference back to it. If you can’t draw it, you can’t explain it.

Prepare for “what if” questions. Judges will always push on scalability, failure modes, and edge cases. “What happens when the system is down?” “What if the data volume triples?” “What if a new acquisition adds 50,000 users?” Have a mental framework for answering these: acknowledge the concern, explain your mitigation strategy, and describe how the architecture would evolve.

Know when to say “I’d need more discovery.” It’s perfectly acceptable — and often the right answer — to say “I’d want to validate this assumption with the business before committing to this design.” Judges respect intellectual honesty far more than overconfident hand-waving. The key is to still provide a recommended direction while noting where you’d seek additional input.

Practice the clock. In a real CTA board review, time management is everything. Spend the first 10 minutes reading and planning. Spend the next 25 minutes building your solution and drawing diagrams. Reserve the last 10 minutes for the Q&A. If you’re still drawing diagrams when the judges start asking questions, you’ve mismanaged your time.

The CTA board review is ultimately a test of whether you can think like an architect under pressure. The scenarios are vehicles for that test. Master the process, and you can solve any scenario they put in front of you.