Clean Bikes

Study Note

This page brings together public scenario links and AI-assisted research notes for study use. Start with the scenario brief, make your own attempt, and open the spoiler section only when you are ready to compare.

Scenario Snapshot

Field	Detail
Start here	Public scenario brief mirror
Scenario source	Official or official-adjacent scenario
Current status	Retired Official
First public date	N/A
Primary source	Open primary source
Coverage available	Scenario brief + Discussion or analysis

Only Open If You Have Attempted the Scenario

The section below contains public follow-up links, board-call material, and AI-assisted notes compiled from those public sources.

Open follow-up links, Q&A, and analysis

Follow-Up Links

Board Insights & Common Pitfalls

Generalized Judge Questions

High-Frequency GPS: “How do you handle 10,000 bikes pinging status every minute? Where do you filter this data so it doesn’t crash the Salesforce event buffer?”
Rental Security: “How do you ensure a Maintenance Provider only sees bikes currently assigned to them for repair? Describe the sharing rule vs. Apex sharing trade-off.”
Dead-Zone Mobile: “Bikes are often in ‘dead zones’ with no signal. How does your mobile app handle the ‘Unlock’ command when the phone is offline?”
Payment Resilience: “What happens if the payment gateway fails at the end of a ride? How do you prevent ‘Ghost Rentals’ from blocking bike availability?”
License Justification: “Why give Maintenance Providers Partner Community licenses instead of standard CC? What CRM objects do they need to access?”

Common Mistakes

Direct IoT Ingestion: Proposing that bikes ping Salesforce directly via REST API for every GPS update. This hits concurrency and API limits instantly.
Public Write for Rentals: Using a Public Read/Write model for rentals to avoid sharing complexity is a critical privacy failure for B2C customer data.
Ignoring Offline Caching: Not implementing offline priming in the Mobile SDK prevents users from finding or locking bikes in low-signal areas.
Master-Detail Skew: Making Bikes a parent of Rentals in a Master-Detail relationship causes row-lock issues on high-turnover bike assets.

Strong Patterns

Heroku Buffer Layer: Using Heroku to ingest 100% of IoT bike traffic and only syncing “Actionable Status Changes” (e.g., Damaged, Battery Low) to Salesforce.
LWC Geolocation: Using a custom LWC with the Google Maps API to find the “Nearest Dock” using the SOQL DISTANCE() formula.
Social Identity for B2C: Using Social Sign-On (Facebook/Google) to minimize onboarding friction for high-volume B2C bike users.

Strategic Insights

The “Asset-Turnover” Test: Clean Bikes probes the architect’s ability to manage high-velocity assets (bikes) and the resulting high-volume transactional data (rentals).
Service at Scale: Success depends on reliable automated assignment logic that routes broken bikes to the nearest maintenance provider without manual triage.

Additional Notes

Global bike-sharing scenario focusing on B2C mobile interactions, IoT status tracking, and third-party maintenance logistics.
Retired official Salesforce Review Board scenario.

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.