Clean Bikes

AI-Assisted 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 + Solution + Discussion or analysis

Why This Scenario Matters

• This entry is included because it appears in the public CTA scenario corpus and has enough public evidence to track for study use.

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

• Public scenario brief mirror
• Analysis reference

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, which hits concurrency and API limits instantly.
• Public Write for Rentals: Using a Public Read/Write model for rentals to avoid sharing complexity, which is a critical privacy fail for B2C customer data.
• Ignoring Offline Caching: Failing to implement offline priming in the Mobile SDK, preventing users from finding or locking bikes in low-signal areas.
• Master-Detail Skew: Making Bikes a parent of Rentals in a Master-Detail relationship, causing 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: Leveraging Social Sign-On (Facebook/Google) to minimize onboarding friction for high-volume B2C bike users.

Strategic Insights

• The “Asset-Turnover” Test: Clean Bikes tests the architect’s ability to manage high-velocity assets (bikes) and the resulting high-volume transactional data (rentals).
• Service at Scale: Success depends on a robust 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.