Lesson 1: What a Salesforce System Architect Actually Does

"Architect" is the most overloaded title in the Salesforce ecosystem. Companies hand it to whoever draws the org chart, and consulting firms put it on any senior consultant. But Salesforce itself defines the role precisely, and there is a certification ladder that tells you what each tier of architect is responsible for. This lesson is the map for the whole track: what the roles are, how the credentials stack, and where it all ends (spoiler: CTA).

What "architect" means on Salesforce

Salesforce's own definition is the one to internalize:

Salesforce Architects are big-picture thinkers and in-depth problem solvers. They design systems for the long-term that stand up to high volumes and won't fail at critical points. ¹

Two phrases there do the heavy lifting. "For the long-term": an architect is optimizing for the org's state five years out, not the demo next week. "Won't fail at critical points": high volumes, security boundaries, integration failures, release windows. The architect is the person who answers "what happens when this scales / when this breaks / when this gets hacked?" before anyone ships.

A working definition for this track: an architect translates business requirements into a platform design that is secure, scalable, maintainable, and deliverable, then defends that design through delivery.

The three-tier certification arc

Salesforce organizes architect credentials into two "domain" architect certifications, and one pinnacle credential above them both. ¹

1. Application Architect: the on-platform owner

Certified Application Architects have a deep understanding of native Salesforce features and functionality. They're also experts at modeling a role hierarchy, data, and appropriate sharing mechanisms. ²

The Application Architect owns what happens inside Salesforce: the data model, the sharing and visibility model, and native features. The credential is granted automatically after four prerequisites:

• Salesforce Certified Platform App Builder
• Salesforce Certified Platform Data Architect
• Salesforce Certified Platform Developer I
• Salesforce Certified Platform Sharing and Visibility Architect

²

2. System Architect: the between-systems owner

Certified System Architects focus on off-platform systems, integration, and securing access between systems. They're also skilled at managing governance and testing capabilities for deployment and ongoing Salesforce modification requirements. ³

The System Architect owns what happens between systems: integration architecture, identity and access between systems, and the release/governance machinery that keeps changes safe. The credential is granted automatically after four prerequisites:

• Salesforce Certified Platform Developer I
• Salesforce Certified Platform Development Lifecycle and Deployment Architect
• Salesforce Certified Platform Identity and Access Management Architect
• Salesforce Certified Platform Integration Architect

⁴

Note the split: it's the mental model that will organize this entire track:

Salesforce classifies both credentials as Advanced level, Architect role. ⁴

3. Technical Architect (CTA): the endgame

Salesforce Certified Technical Architects have experience in designing and implementing secure, high-performance, integrated technical solutions using the Lightning platform within the context of a client's architectural landscape. ⁵

The CTA is the pinnacle credential. It requires both the Application Architect and System Architect credentials as prerequisites ⁵, and then a two-step evaluation: an Architect Evaluation, then the Architect Review Board Exam. ⁶

Salesforce's own blog calls CTAs "the pinnacle credential holder" and "quite rare gems." ⁷ The history explains why the bar is high:

• The CTA credential launched in 2011; the first 10 CTAs were certified in September of that year.
• The Architect Academy launched in February 2016, the first official CTA preparation resources.
• At Dreamforce '17, Salesforce introduced the "Architect Journey": domain certifications as stepping stones to the CTA pinnacle.

⁷

So the arc is: eight domain prerequisite exams → Application Architect + System Architect → CTA. That's the mountain. This track is the trail map.

Worked example: who owns what

A client wants Salesforce integrated with their legacy ERP, with single sign-on for all employees, and a governed release process so the integration team can deploy weekly without breaking the org. Here's how the tiers divide the work:

• Application Architect: designs the Salesforce data model (e.g., how the ERP's orders map to custom objects and fields), the role hierarchy, and the sharing rules so each department sees only its records. Owns "inside the org."
• System Architect: designs the integration: how Salesforce and the ERP exchange data (API choice, sync vs async, error handling), how SSO federates identity into Salesforce, and the sandbox → production deployment pipeline with change governance. Owns "between systems."
• CTA: sits above both. The CTA weighs the tradeoffs end to end: is a custom integration better than a managed package? Is SSO via an existing IdP enough, or does the identity model need rework? When requirements conflict, the CTA makes the call and defends it. The Review Board exam is precisely this: a rigorous, scenario-based defense of a complete architecture. ⁷

The pitfall to avoid

Treating the certificate as the job. The System Architect certification is a gate: it proves you passed the four prerequisite exams, but the role is judgment: choosing between a synchronous REST call and a queued batch when the ERP is down, deciding where identity lives, designing a governance model that developers will actually follow. The exams test that you know the platform's patterns; the career is about knowing when to use them. Trailhead's career path says it best: "Good architecture is about balancing what works today with what will scale tomorrow." ⁸

A second, subtler trap: mixing up the two domain architects. "System Architect" is not "the architect who knows everything about systems." It is specifically the off-platform concern (integration, identity, governance), while the Application Architect owns the on-platform concern (data, sharing, native features). Getting that split wrong on an exam question is the fastest way to lose points. Get it wrong in a real org and you'll have two teams designing past each other.

Try it

For each of these five requirements, decide: does it belong to the Application Architect's domain (on-platform) or the System Architect's domain (off-platform)?

1. "Sales reps need partner accounts to see only their own pipeline."
2. "Orders must flow from Salesforce to the ERP every 15 minutes."
3. "Employees log in with their corporate Okta credentials."
4. "The integration team needs a sandbox that mirrors production data."
5. "Opportunity stages must be standardized across all business units."

Then write one sentence for each naming the specific prerequisite credential that maps to it (e.g., #2 → Platform Integration Architect). When you're done, check the answers against the prerequisite lists linked in the Sources below.

What's next

This lesson was the map. Lesson 2 starts the foundation every System Architect topic sits on: multi-tenant platform architecture. You will learn how the shared instance model works, how orgs and environments such as Dev, QA, UAT, and Prod relate to each other, and why every design decision you make later assumes the multi-tenant constraints you meet there.