Q1. Scenario: Your organization needs to integrate Salesforce with multiple external systems (ERP, billing, and analytics). As an architect, how do you decide which Salesforce integration option to use?
Answer:
I start by evaluating data volume, real-time vs async needs, ownership of data, and latency tolerance.
For real-time transactional access, REST APIs are preferred.
For large data loads (>2000 records), Bulk API 2.0 is ideal due to async processing.
If data must not be stored in Salesforce and must always be fresh, I use Salesforce Connect with External Objects.
For event-driven integration, Streaming APIs (Platform Events / CDC) are chosen.
This architectural decision ensures scalability, performance, and data consistency.
Q2. Scenario: A business wants near real-time updates in an external system whenever a Salesforce record changes. What integration pattern would you suggest?
Answer:
I would recommend an event-driven architecture using Streaming APIs, preferably Change Data Capture (CDC). CDC automatically publishes events when records change, avoiding custom triggers. This approach improves scalability.
Q3. Scenario: Multiple external applications need to access Salesforce APIs securely. How do you design the authentication model?
Answer:
I design a Connected App per trust boundary, not per application blindly. Each connected app has:
- Least-privilege OAuth scopes
- Defined OAuth flow (JWT or Web Server or as per scenario details available)
- IP relaxation policies only if required
This isolates security risks and allows fine-grained access control.
Q4. Scenario: Why would you avoid sharing a single Connected App across multiple integrations?
Answer:
Sharing a connected app increases risk if credentials are compromised. From an architectural standpoint, separate connected apps allow:
- Independent rotation of secrets
- Flow-specific security settings
📘[Explore the course]
No comments:
Post a Comment