Solution: UrbanNest Home Goods

Work in Progress

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

Architecture Decisions

AD-1: Keep Shopify Plus: Do Not Migrate to Commerce Cloud B2C

Decision: Retain Shopify Plus as the DTC e-commerce platform. Do not migrate to Salesforce Commerce Cloud B2C in phase 1 or phase 2.

Rationale:

The case for keeping Shopify is strong on every dimension the board is likely to probe.

• Four years of front-end investment and 18 months of estimated development effort (Room Builder, lookbook, bundle pricing, loyalty) cannot be replicated in an 8-month window on any platform.
• Commerce Cloud B2C migration would consume the entire $600K budget and timeline with no capacity left for the B2B channel — which is the actual business driver.
• Shopify Plus handles the current volume comfortably. At 280 baseline orders/day and 1,100 during seasonal peaks, UrbanNest is well within Shopify Plus capacity limits.
• The Head of E-commerce has a legitimate technical objection. A migration would require her team’s full focus during a period when the spring seasonal sale must run without disruption. The freeze window falls 3 months into the project — a migration that early is not viable.
• Shopify REST Admin API and webhook support provide all the integration surface area needed for the Salesforce connectivity required by the project.

What a migration would gain: A single platform for both channels, unified product catalog, native Salesforce reporting. These are real benefits but they are phase 3 considerations, not phase 1 constraints.

Future-state note: If UrbanNest’s B2C requirements eventually exceed Shopify Plus (international expansion, complex B2C account relationships, native CRM-commerce fusion), a Commerce Cloud migration can be re-evaluated in year 3 with a proper business case. That sequencing should be named explicitly so stakeholders understand the decision is not permanent.

---

AD-2: Salesforce B2B Commerce (Lightning Experience) for the Wholesale Channel

Decision: Use B2B Commerce (Lightning Experience), Salesforce’s Commerce Cloud B2B edition, as the wholesale buyer portal, not a custom-built Experience Cloud portal.

Rationale:

• B2B Commerce natively supports account hierarchies (parent/child), contract-based pricing and price books, self-service order placement, and buyer-scoped data isolation — all stated requirements.
• Building equivalent functionality with custom Apex, LWC, and Experience Cloud from scratch would require 3-4x more development effort and produce a higher-risk, harder-to-maintain result.
• A custom portal built to meet the same requirements would be indistinguishable from B2B Commerce in the end state, but with no vendor-maintained upgrade path.
• The 3-person internal team can be trained on B2B Commerce administration. A bespoke portal creates a maintenance burden they cannot absorb.
• B2B Commerce runs on the same Salesforce org, sharing the CRM data layer — accounts, contacts, orders, pricebooks. No cross-system data duplication for wholesale.

Licensing note: B2B Commerce is a paid product , pricing varies by edition and contract; typically based on GMV or storefront licensing. This must be factored into the $600K budget. Budget analysis should confirm licensing headroom for the projected 60+ account scale by end of year 2.

---

AD-3: MuleSoft vs Native Salesforce Connectors vs Lightweight iPaaS

Decision: Use a lightweight, code-minimal iPaaS (Boomi, Workato, or MuleSoft Anypoint Starter tier) rather than point-to-point Apex callouts for both Shopify and FulfillEdge integrations.

Rationale:

• Requirement 18 explicitly states the architecture must accommodate additional system connections (accounting, returns management) without re-architecting existing integrations. Point-to-point Apex callouts do not satisfy this requirement — each new system creates a new independent connection that adds to the maintenance surface.
• A lightweight iPaaS provides a single operational pane for monitoring, retrying failed events, and adding flows. The ops team of 1-2 people can manage this without deep Apex knowledge.
• MuleSoft Anypoint (full tier) is the premium choice and the most defensible in a CTA board context, but its cost at this company size may exceed budget constraints. A lower-cost alternative (Boomi Essentials, for instance) achieves the same architectural pattern at lower licensing cost. Name the trade-off explicitly.
• If budget absolutely prohibits middleware, a Salesforce Platform Events + Apex async queue pattern is a defensible fallback, but acknowledge the trade-off: error visibility and retry logic must be built custom.

Constraint check: The constraint states UrbanNest does not currently have an integration platform and the post-launch team must be able to operate it. This rules out bespoke middleware and reinforces the iPaaS choice.

---

AD-4: Single Org, Shared Data Layer

Decision: One Salesforce org for Sales Cloud (CRM), B2B Commerce, and Experience Cloud (buyer portal). No multi-org.

Rationale: Data volumes are explicitly called out as modest (under 100 B2B accounts, 1,400 SKUs). The unified customer view requirement (Req 19) and the marketing requirement (Req 21) both depend on DTC and wholesale data living in the same org. A multi-org approach would reintroduce the silos the project is chartered to eliminate.

---

System Landscape

The iPaaS layer sits between all external systems. Salesforce is the system of record for accounts, contacts, wholesale orders, pricing, and AR. Shopify remains the system of record for DTC transactions. FulfillEdge is the system of record for inventory and fulfillment.

---

Data Model

Customer 360 , Unified Person Record

The central design challenge is linking a person who exists as a Shopify customer (DTC) and as a Contact on a wholesale account (B2B). The approach:

• Person Account or Contact + Account depending on org configuration. For UrbanNest, standard Contact records attached to a wholesale Account are appropriate. Person Accounts are not recommended here because they complicate the Account hierarchy model.
• A Custom Field on Contact: Shopify_Customer_ID__c links the Contact to their Shopify customer record. The integration layer uses email address as the match key when syncing Shopify customers.
• DTC order history is stored as a custom object DTC_Order__c (or a standard Order record with a channel field) linked to the Contact. Service agents see both wholesale orders (standard Order object) and DTC orders in a single record page.
• Duplicate management: Salesforce Duplicate Rules with matching on email address prevent a second Contact from being created when a wholesale buyer is also a DTC customer.

Account Hierarchy for B2B

Account (Parent)
  └─ Name: "Pacific Design Group" (the buying organization)
  └─ Fields: Pricing Tier, YTD Revenue, Credit Limit, AR Balance, Payment Terms
  └─ Child Accounts (individual store locations)
        └─ Name: "Pacific Design Group ,  Berkeley"
        └─ Name: "Pacific Design Group ,  Oakland"
        └─ Each child can place independent orders
        └─ AR and tier rolled up to parent account

The standard Salesforce Account object’s ParentId field implements the parent/child hierarchy. No custom objects needed.

Product and Pricebook Structure

• Product2 object with 1,400 active SKUs synced from FulfillEdge (the inventory master) or Shopify (the catalog master — to be confirmed with UrbanNest). One sync direction; no bidirectional product writes.
• Standard Price Book: MSRP (retail reference)
• Three wholesale price books: Tier 1 (40% off), Tier 2 (30% off), Tier 3 (20% off)
• B2B Commerce assigns the correct price book to each buyer account. Contract-based pricing in B2B Commerce maps to Salesforce Price Books.
• Quarterly tier review: a Scheduled Flow or batch process re-evaluates each account’s trailing 3-month order volume and updates the Pricing_Tier__c field on the Account, which triggers reassignment to the appropriate price book.

B2B Order Objects

• Order (standard) linked to the child Account for each wholesale order
• OrderItem (standard) for line items
• Custom fields: Net_Payment_Terms__c, PO_Number__c, Invoice_PDF_URL__c, Overdue_Flag__c
• FulfillEdge_Order_ID__c on Order for cross-system tracing

---

Integration Architecture

Integration 1: Shopify to Salesforce (Order and Customer Data)

Dimension	Detail
Trigger type	Shopify webhook (order/create, order/updated)
Direction	Shopify to Salesforce (via iPaaS)
Latency target	Within 10 minutes of event (Req 13)
Data payload	Order ID, line items, customer email, shipping address, payment status, tracking number
Match key	Customer email mapped to Contact.Email; Shopify Order ID stored on DTC_Order__c
Upsert logic	Create DTC_Order__c if new; update existing if order status changes
Error handling	iPaaS logs failed events; ops dashboard shows failure count and payload; manual retry available

The iPaaS subscribes to Shopify webhooks. On receipt, it performs an email lookup against Salesforce Contacts. If a match is found, the order is linked to that Contact. If no match, a new Lead or Contact is created (decision to be confirmed with sales ops — Leads are not ideal for wholesale but may be appropriate for DTC-only customers not yet in CRM).

Integration 2: FulfillEdge to Shopify (Inventory Sync)

Dimension	Detail
Trigger type	FulfillEdge webhook (inventory level change) or scheduled polling every 15 minutes
Direction	FulfillEdge to Shopify (via iPaaS)
Latency target	Within 30 minutes of stock movement (Req 14)
Data payload	SKU, warehouse location, on-hand quantity
Shopify update	Inventory Levels API to update available quantity per location
Error handling	Logged in iPaaS; ops alert if update fails; last-known-good inventory held until retry succeeds

This integration directly resolves the oversell problem. Webhook-triggered is preferred over polling; polling at 15-minute intervals is a fallback if FulfillEdge’s webhook reliability is uncertain at first. Confirm with FulfillEdge that their REST API v2.4 inventory webhooks fire on every stock movement, including putaway and adjustments.

Integration 3: Salesforce to FulfillEdge (B2B Fulfillment Orders)

Dimension	Detail
Trigger type	Salesforce Platform Event or outbound message on Order status = “Confirmed”
Direction	Salesforce to FulfillEdge (via iPaaS)
Latency target	Within 5 minutes of B2B order confirmation (Req 15)
Data payload	Order ID, line items with SKU and quantity, ship-to address, buyer PO number, net terms
FulfillEdge action	Create fulfillment order via REST API v2.4
Error handling	iPaaS retries on HTTP 5xx; if FulfillEdge is unavailable, event is queued and retried up to 3 times before alerting ops

Integration 4: FulfillEdge to Salesforce (Shipment Tracking)

Dimension	Detail
Trigger type	FulfillEdge shipment webhook (carrier assigned, tracking number issued, delivery confirmed)
Direction	FulfillEdge to Salesforce (via iPaaS)
Latency target	Within 15 minutes of shipment event (Req 16)
Data payload	FulfillEdge Order ID, carrier name, tracking number, estimated delivery, delivery confirmation timestamp
Salesforce update	Update Order record tracking fields; Experience Cloud buyer portal reflects updated Order status in real time
Error handling	Same logging and retry pattern as above

Error Handling Architecture (Req 17)

All four integrations route through the same iPaaS error handling pattern:

1. Failed event is logged with timestamp, source system, payload, and HTTP error code
2. Automatic retry: 3 attempts with exponential backoff (30s, 2m, 10m)
3. If all retries fail: alert to ops email/Slack channel + entry in a custom Salesforce object Integration_Error_Log__c visible on the ops dashboard
4. Manual retry: ops team can re-trigger the event from the iPaaS console without reprocessing the entire batch

---

Security and Sharing Model

B2B Buyer Portal Access (Req 11)

The buyer portal runs on Experience Cloud using B2B Commerce buyer licenses (Buyer User / Buyer Manager) , specific external license types for the B2B Commerce storefront. Access scoping uses:

• External Account Hierarchy sharing: each Contact is associated with a single Account (or child Account). Experience Cloud sharing rules prevent cross-account data access at the record level.
• B2B Commerce buyer groups: each buyer is assigned to a buyer group that maps to their account and pricing tier. Product visibility, price book assignment, and order access are all scoped to the buyer group.
• Profile + Permission Set architecture: External Partner User profile with minimum permissions. No access to internal Salesforce objects. Read-only on Product2. Read/Write on their own Orders and Contacts.

A buyer logged in as “Pacific Design Group , Berkeley” sees only that location’s orders, invoices, and account balance. They cannot see another buyer’s data, UrbanNest’s internal CRM records, or pricing tiers other than their own.

Dealer Pricing Isolation

Price books are never exposed to buyers directly. The B2B Commerce storefront resolves pricing through Buyer Groups linked to Buyer Group Price Books / Web Store Price Books , the buyer sees only their own net price at catalog render time. The MSRP and other tier prices are not accessible to the authenticated buyer. Sharing rules and field-level security on PricebookEntry restrict read access to internal users only.

Internal CRM Access , Sales Reps vs Service Agents

Sales reps: full read/write on Accounts, Contacts, Opportunities, Orders, and B2B Commerce order data. No access to DTC order detail beyond what is surfaced in the service view.

Service agents: read-only on DTC Order records, read on Account/Contact/Cases, no access to wholesale pricing or contract terms beyond what is needed to resolve a service issue.

Finance: read/write on AR-related fields (AR_Balance__c, Overdue_Flag__c, Invoice_PDF_URL__c). Read-only on Order and OrderItem.

---

Migration Strategy

Customer Data Unification

UrbanNest has no existing Salesforce org. This is a greenfield implementation. The migration work is:

1. Export the 18-22 active wholesale accounts from the Google Sheet. Clean and load as Accounts (parent) with child Accounts for each physical store location. Load Contacts for each buyer contact.
2. Assign pricing tiers to each account based on historical order data in the spreadsheet.
3. Run a Shopify customer export. For any email that matches an imported Contact, populate Shopify_Customer_ID__c on the Contact record. This establishes the DTC/wholesale link at go-live.
4. Historical DTC orders: decide with UrbanNest whether to backfill DTC order history into Salesforce. Recommendation: load the trailing 12 months of Shopify orders for any customer who is also a wholesale Contact. Older history can remain in Shopify and accessed via the Shopify admin if needed.

Product Catalog Sync

Determine the catalog master system. Recommended: FulfillEdge is the inventory and quantity master; Shopify is the product description and media master. Salesforce Product2 records are populated from a one-time export of active SKUs from Shopify (title, description, SKU, MSRP). Ongoing product adds and retires are maintained manually by the admin team in Salesforce, synced to Shopify as needed. At 1,400 SKUs and a small product team, automated bidirectional product sync adds complexity that is not justified by the data volume.

---

Reporting Approach

Report	Owner	Source	Delivery
Weekly wholesale pipeline	VP of Sales (Req 23)	Salesforce Accounts, Opportunities, Orders, AR fields	Salesforce Report scheduled weekly
Monthly revenue summary DTC + B2B (Req 24)	COO	B2B: Salesforce Orders. DTC: DTC_Order__c synced from Shopify	Combined Salesforce Dashboard or CRM Analytics report joining both objects
BOPIS weekly fulfillment view (Req 25)	Store managers	DTC_Order__c with fulfillment_type = BOPIS, joined to FulfillEdge shipment status	Salesforce Report filtered by store location, delivered via email or Experience Cloud store manager tab

Note on Req 24 (channel gross margin): Gross margin tracking requires cost-of-goods data. If UrbanNest does not currently track COGS per SKU in any system, this report can only be built once COGS are added to Product2 or imported from an accounting system. Flag this dependency to the COO during discovery.

---

Requirements Addressed

#	Requirement	How Addressed
1	Keep or migrate Shopify vs Commerce Cloud B2C	AD-1: Keep Shopify. Rationale covers timeline, investment, and risk.
2	Dedicated B2B platform, not custom build	AD-2: Salesforce B2B Commerce managed package.
3	Single org, shared data layer	AD-4: One org. Shared Product2, Account, Contact, Order objects.
4	Phased rollout: 18 accounts then 60+	B2B Commerce scales to hundreds of accounts. No re-architecture required. Buyer group model supports phased onboarding.
5	Preserve Shopify customizations in phase 1	Shopify not touched during phase 1. All integration is additive (webhooks, API calls). No storefront changes required.
6	Self-service buyer portal	Experience Cloud + B2B Commerce: catalog browse, order placement, order status, invoice download.
7	Tiered pricing (Tier 1/2/3)	Three wholesale price books. Quarterly review via Scheduled Flow on account order volume.
8	Account hierarchies: parent org + child store locations	Standard Account ParentId hierarchy. Each child Account places independent orders. AR rolls to parent.
9	Net-30 PO payment terms + AR tracking	Custom fields on Order. Finance dashboard with AR balance and overdue flag per account.
10	Account onboarding approval workflow	Salesforce Approval Process: sales rep submits, credit review step (manual action, 1-3 day SLA), auto-activation on approval with tier assignment.
11	Portal access scoped to buyer’s own account	External Account Hierarchy sharing + B2B Commerce buyer groups. No cross-account visibility.
12	Sales rep CRM view of wholesale pipeline	Sales Cloud standard Opportunity and Account management. Custom report tabs for open orders, YTD revenue, AR, tier status.
13	Shopify orders to Salesforce within 10 minutes	Shopify order webhooks processed by iPaaS. Target latency under 5 minutes in normal operation.
14	Inventory sync FulfillEdge to Shopify within 30 minutes	FulfillEdge inventory webhooks or 15-minute polling to Shopify Inventory Levels API via iPaaS.
15	B2B confirmed order to FulfillEdge within 5 minutes	Platform Event on Order status change triggers iPaaS flow to FulfillEdge REST API.
16	Shipment tracking to portal and CRM within 15 minutes	FulfillEdge shipment webhooks update Order tracking fields in Salesforce. Portal reads live from Order record.
17	Error handling: log, visible to ops, retriable	iPaaS error log + Integration_Error_Log__c object in Salesforce. Ops alert on failure. Manual retry from iPaaS console.
18	Integration architecture extensible for new systems	iPaaS hub-and-spoke model. New systems added as new flows without changing existing connections.
19	Unified customer view: DTC + wholesale	DTC_Order__c linked to Contact. Service console shows both order types on one record.
20	No duplicate person records for DTC + wholesale customers	Duplicate Rules on email. Shopify_Customer_ID__c on Contact links the two identities.
21	Marketing visibility into wholesale engagement	Wholesale account data (last order, AOV, tier) on Account record. Marketing can build List Views and Reports directly. No CRM export required.
22	Order lookup by Shopify order number without switching tools	Shopify Order Number stored on DTC_Order__c. Service agent searches by order number in Salesforce. FulfillEdge tracking status synced to the record.
23	Weekly wholesale pipeline report	Salesforce Report on Accounts + Orders + AR fields. Scheduled weekly to VP of Sales.
24	Monthly DTC + B2B revenue summary with margin	Salesforce Dashboard combining DTC_Order__c and Order objects. COGS dependency flagged.
25	BOPIS weekly fulfillment view for store managers	DTC_Order__c filtered by fulfillment_type = BOPIS and store location. Scheduled report or Experience Cloud tab.

---

Risk Assessment

Risk 1: Spring Seasonal Sale Freeze Window

The spring sale event falls approximately 3 months into the project. This creates a hard freeze window for any changes to Shopify or its integration layer. The integration between Shopify and Salesforce must be designed, tested, and deployed either before the freeze begins or after the sale ends. Given that Shopify integration is in the critical path for service visibility (Req 13) and inventory sync (Req 14), the project plan must sequence Shopify integration in months 1-2. If that is not achievable, the integration goes live after the sale, and the spring sale runs with the current manual inventory update process. The ops team should plan for this contingency.

Risk 2: B2B Commerce Licensing Cost vs $600K Budget

B2B Commerce is a paid product with pricing that varies by edition and contract , typically based on GMV or storefront licensing , and must be validated against the $600K budget early in discovery. At 18 initial buyer accounts scaling to 60+, licensing cost needs to be confirmed before the architecture is locked. If full B2B Commerce licensing exceeds budget, the fallback is a lighter Experience Cloud partner community with custom Apex and LWC for order management — still not a custom portal from scratch, but more build work. Name this risk explicitly in the presentation and show that you have explored both options.

Risk 3: FulfillEdge Webhook Reliability

The inventory sync (Req 14) and fulfillment order tracking (Req 16) both depend on FulfillEdge webhook delivery being reliable. FulfillEdge is described as a mid-market SaaS WMS. If their webhook infrastructure has reliability issues (delayed delivery, missed events), the 30-minute inventory sync target is at risk. Mitigation: supplement webhooks with a 15-minute polling fallback on inventory. For shipment tracking, implement a daily reconciliation batch that checks for Orders with confirmed status but no tracking update older than 2 hours.

Risk 4: Internal Team Capacity After Go-Live

A 3-person tech team (1 admin, 1 developer, 1 IT ops) maintaining Salesforce B2B Commerce, Shopify Plus integrations, FulfillEdge integrations, and an iPaaS platform is a thin operational footprint. The architecture must minimize custom code in favour of configuration. The iPaaS selection should weight ease-of-administration. Flows over Apex wherever possible. Document all integration flows and error procedures before the SI engagement ends. Recommend a 3-month hypercare period with the SI post-launch.

---

Domain Scoring Notes

Solution Architecture Judge Probes

The Solution Architecture judge will probe whether you can justify the build-vs-buy decisions with business context, not just product features. Be ready for:

• “Why not Commerce Cloud B2C? What would it take to make that the right answer?” , Answer: timeline, investment, and no demonstrable gap in Shopify’s capability for the current DTC use case. Commerce Cloud becomes relevant when DTC revenue requires features Shopify cannot provide: complex B2C account relationships, multinational tax and compliance at scale, native AI merchandising at a level Shopify’s ecosystem cannot match.
• “Why B2B Commerce over a custom Experience Cloud portal?” , Answer: build-vs-buy. B2B Commerce ships the exact features required. A custom build produces the same result with more risk, more time, and more ongoing maintenance for a 1-person admin team.
• “How does the org scale to 60+ accounts by year 2?” , Answer: B2B Commerce and Sales Cloud scale to thousands of accounts. The architecture does not change; only buyer group membership and price book assignments grow. No re-architecture required (satisfying Req 4).

Integration Judge Probes

The Integration judge will test whether you understand the failure modes and operational realities of the integration layer:

• “What happens if FulfillEdge goes down during a busy period?” , Answer: iPaaS queues outbound fulfillment order events. When FulfillEdge recovers, events process in order. The B2B buyer portal shows the order as “Processing” (not yet fulfilled) until FulfillEdge confirms receipt. No data loss; the queue preserves ordering.
• “How do you prevent inventory oversells during the seasonal spike?” , Answer: FulfillEdge webhook triggers near-real-time inventory updates to Shopify (target under 30 min). At 1,100 orders/day during a spike, that is roughly 1 order per 80 seconds average — the 30-minute window means Shopify inventory could be up to 30 minutes stale at worst. For high-velocity SKUs, consider reducing the polling interval to 5 minutes during the sale window. Alternatively, implement a reserve-on-cart pattern in Shopify, but that is a Shopify customization, not a Salesforce concern.
• “What is your error handling strategy if the Shopify-to-Salesforce webhook fails for 2 hours?” , Answer: iPaaS will have retried and escalated to an ops alert within the first 30 minutes. The ops team can manually trigger a Shopify order export for the missed window. No orders are lost; Shopify is the source of truth for DTC orders. The Salesforce record is eventually consistent, not a transactional dependency for order completion.

---

What Would Fail

Anti-pattern 1: Migrating Shopify to Commerce Cloud B2C to “unify the platform.”

This is the most common wrong answer for this scenario. It fails on budget, timeline, and stakeholder alignment simultaneously. The COO chartered the project to launch B2B — not to rebuild DTC. The CEO and Head of E-commerce have both signalled strong resistance. A CTA who recommends a platform migration without a concrete business gap that Shopify cannot address is not listening to the client. The board will probe this hard.

Anti-pattern 2: Building a custom wholesale portal with Experience Cloud LWC components instead of using B2B Commerce.

This fails the build-vs-buy test. If you propose building account hierarchy management, tiered pricebook assignment, self-service order placement, and invoice download from scratch using Apex and LWC on Experience Cloud, you are reinventing B2B Commerce at a higher cost and lower quality. The internal team of 1 admin cannot maintain bespoke Apex at scale. The right answer is to use the product that ships what is needed.

Anti-pattern 3: Point-to-point Apex callouts for Shopify and FulfillEdge integrations.

This directly fails Req 18. If Shopify calls are implemented as one set of Apex classes and FulfillEdge calls are another, adding an accounting system integration requires a third independent set of custom code. There is no shared error handling, no unified retry mechanism, and no operational dashboard. The 3-person tech team ends up debugging Apex logs in production to understand why an order did not flow. A middleware layer or iPaaS is not gold-plating for this scenario — it is explicitly required by the stated constraint.

---

Scoring Rubric

Criterion	Weight	What Earns Full Credit
Platform strategy (AD-1 and AD-2)	25%	Clear keep/build/buy rationale grounded in the client’s constraints, timeline, and stated requirements. Commerce Cloud B2C migration rejected with specific reasoning, not just dismissed. B2B Commerce selected with trade-off acknowledged.
Integration architecture	25%	All four integration flows named with trigger type, direction, latency target, and error handling. Middleware/iPaaS chosen with justification tied to Req 18. Failure mode for each integration addressed.
Data model completeness	20%	Account hierarchy, Contact/Shopify link, Price Books, Order/OrderItem all addressed. Duplicate strategy for DTC+B2B person records present.
Security and access model	15%	B2B portal scoping to account level explained. Price isolation addressed. Internal role separation named.
Requirements coverage	15%	All 25 requirements addressed (at least acknowledged). No requirement silently dropped. Implicit requirements (spring sale freeze, team capacity, COGS dependency) surfaced.

---

Self-Assessment Checklist

• Did I explicitly reject Commerce Cloud B2C with client-specific reasoning, not just “Shopify is fine”?
• Did I name B2B Commerce (not a custom Experience Cloud portal) as the wholesale platform and justify it as a build-vs-buy decision?
• Did I draw or describe all four integration flows with trigger type, direction, and latency target?
• Did I address the spring seasonal sale freeze window and its impact on the integration delivery sequence?
• Did I describe how a person who is both a Shopify customer and a wholesale Contact is represented in Salesforce without duplication?
• Did I explain how the buyer portal is scoped so each buyer sees only their own account data?
• Did I name the COGS dependency for the COO’s gross margin report?
• Did I identify at least one risk tied to the 3-person internal team’s operational capacity post-launch?

---

Q&A Prep

Q: The CEO says she does not want to disrupt the Shopify experience. Does your architecture touch Shopify at all?

A: Only at the integration layer. We add outbound webhooks for order and inventory events — these are configuration changes in Shopify Plus, not storefront changes. The Room Builder, lookbook, discount engine, and loyalty app are untouched. The Shopify storefront the DTC customer sees is identical before and after the project.

Q: What if B2B Commerce licensing is too expensive for a $600K budget?

A: We need to validate licensing cost early in discovery — before committing to the architecture. If full B2B Commerce exceeds budget, the fallback is an Experience Cloud Partner Community with a lighter custom order management build. That is more implementation effort and a higher maintenance burden for the internal team, but it is a viable option. The recommendation stands as B2B Commerce; the budget constraint is a risk to surface immediately, not a reason to abandon the recommendation without a cost analysis.

Q: How do you handle the account hierarchy when a dealer manages 15 store locations?

A: Standard Salesforce Account ParentId. One parent Account per buying organisation. One child Account per physical store location. Each child Account is assigned to the same buyer group for pricing (inheriting the parent’s tier) but can place independent orders. AR balances roll up to the parent for finance visibility. The sales rep sees the full hierarchy in a single Account page using the Account Hierarchy component.

Q: The VP of Sales says they need tiered pricing reviewed quarterly. How does that work without manual intervention?

A: A Scheduled Flow runs at the end of each quarter, reads trailing 90-day order value per Account, compares it to the three tier thresholds, and updates the Pricing_Tier__c field. A separate Process or Flow step then reassigns the Account’s Buyer Group membership to map to the correct Buyer Group Price Book for the new tier. The sales rep receives a notification of any tier changes for their accounts so they can manage the commercial relationship. The finance team gets a report of all tier changes for that quarter.

Q: What is your plan for the spring seasonal sale that falls 3 months into the project?

A: The spring sale is a hard constraint that defines the delivery sequence. Shopify integration (Reqs 13 and 14) must be live before the sale or deferred until after it. Salesforce B2B setup and the wholesale portal can proceed in parallel during the sale period since they do not touch Shopify. The project plan needs an explicit freeze window: no Shopify changes from 2 weeks before the sale through the sale end date. Integration go-live is planned for month 2 to clear that window.

Q: How do you prevent oversells during the spring sale spike of 1,100 orders/day?

A: The inventory sync integration (FulfillEdge to Shopify) brings inventory data freshness from 24 hours to under 30 minutes. At 1,100 orders/day, that means Shopify inventory is at most 30 minutes stale. For the highest-velocity SKUs, we can tune the FulfillEdge polling interval to 5 minutes during the sale window. If UrbanNest wants a stronger guarantee, a reserve-on-cart configuration in Shopify Plus can hold inventory at add-to-cart. That is a Shopify product decision, not a Salesforce decision.

Q: What does the service agent experience look like when a customer calls about a Shopify order?

A: The service agent searches by Shopify order number in the Salesforce search bar. The DTC_Order__c record shows line items, payment status, shipping address, and current FulfillEdge tracking status — carrier, tracking number, estimated delivery. The agent never opens Shopify or FulfillEdge. The record also shows if the same customer has an open wholesale account or any B2B orders, giving the agent the full relationship context.

Q: How do you handle the case where a wholesale buyer places a DTC Shopify order under a different email address?

A: The integration uses email as the match key. If the buyer uses a different email for DTC, there will be no automatic link to their wholesale Contact. The service agent will see two separate records. The solution is to prompt buyers at checkout to use the same email registered to their wholesale account. A deduplication review process for the admin team can periodically identify and merge records where the same person appears under two emails. This is an operational process, not a fully automated technical solution — and that is an honest answer for this scale of business.

Q: Why not use MuleSoft instead of a generic iPaaS?

A: MuleSoft Anypoint Platform is the architecturally ideal answer and the one the CTA board expects you to know. At UrbanNest’s scale and budget, the licensing cost of full Anypoint may be disproportionate. The architectural pattern is identical: a hub-and-spoke integration layer with managed connectors, a shared error framework, and operational monitoring. If the budget allows, MuleSoft is the recommendation. If budget is tight, Boomi or a comparable mid-market iPaaS delivers the same pattern at lower cost. Name the trade-off rather than presenting either as the only option.

Q: The internal tech team is 3 people. How does this influence your architecture?

A: It is the most important operational constraint in the design. Every decision is tested against “can a 1-person admin maintain this?” That means: Flows over Apex, B2B Commerce over a custom portal, an iPaaS with a UI console over handwritten integration code, and configuration over customisation wherever the requirement allows. Where custom code is necessary (the Shopify customer identity link, the AR overdue flagging logic), it is documented and isolated. The SI engagement should end with runbooks, not just a working system.

Q: The COO wants gross margin by channel. Can Salesforce provide that?

A: Salesforce can provide it once cost-of-goods data is available. The architecture stores DTC orders (from Shopify) and B2B orders (native Salesforce) in the same org. If Product2 records are enriched with a Unit_Cost__c field, a formula field calculates margin per order line. The COO’s dashboard then rolls up margin by channel. The dependency is getting COGS into the product catalogue — that data likely lives in an accounting or ERP system. If there is no accounting integration in phase 1, the gross margin report is a phase 2 deliverable once COGS data is available. Flag this explicitly in the presentation.

---

Presentation Notes

Opening framing: UrbanNest has a B2B growth opportunity with a contractual deadline, a proven DTC operation they cannot risk disrupting, and a small team that must be able to maintain whatever is built. Every architectural decision flows from those three constraints. The platform strategy is not about picking the most sophisticated Salesforce product — it is about picking the right tool for each channel given real-world constraints.

For the board whiteboard: Draw the system landscape early. Label each system as “System of Record” for its domain (Shopify = DTC transactions, FulfillEdge = inventory, Salesforce = customer data + B2B commerce). The iPaaS sits in the middle as the integration hub. This framing makes every subsequent integration discussion easier to follow.

Handling pushback on keeping Shopify: Be direct. “I am recommending keeping Shopify because migrating it would cost more than the total project budget and take longer than the delivery window. The only reason to revisit that is if UrbanNest identifies a specific DTC requirement that Shopify cannot meet. I do not see that requirement in the brief.” If the board pushes a specific capability gap, engage with it — but do not abandon the recommendation without a concrete reason.

Handling the B2B Commerce licensing question: Acknowledge it immediately. “Licensing cost is a risk I would validate in week one of discovery. The architecture is built around B2B Commerce because it is the right product for the requirements. If the cost model does not work at this scale, I have a fallback position and I am happy to walk through it.”

Closing with the implicit requirements: Name the spring sale freeze window, the COGS dependency for margin reporting, and the team capacity constraint explicitly. Boards score candidates who identify what is not stated in the brief as highly as those who answer what is. These three items demonstrate that you read the scenario for operational reality, not just stated requirements.

---

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.