Salesforce Architect Interview Guide

How to use this guide

These questions are based on the interview topics supplied. The answers are study guidance and example designs, not claims about the exact implementation discussed in the interview. Adapt them to the actual product, license, security model and requirements. Be clear about what you personally built versus what you designed or supported.

Key principle: Authentication establishes identity. Authorization determines what that identity may access. A valid login or API token does not automatically grant access to every Salesforce record or Knowledge article.

Answer structure: clarify requirements, state assumptions, explain the architecture, cover the happy path, then discuss security, failure handling, scale, monitoring and trade-offs.

1. Salesforce Knowledge, Azure and GenAI

Explain the complete retrieval-augmented generation (RAG) design, including content ingestion and authorization at query time.

1. You mentioned a Salesforce Knowledge-to-Azure use case. Can you explain the architecture?

Answer

Salesforce Knowledge remains the content system of record. When an article is published or updated, an event-driven or scheduled integration extracts approved content and metadata, normalizes and chunks the text, generates embeddings, and stores vectors plus metadata in Azure AI Search. At question time, an LWC chatbot sends the user’s question to a secured backend. The backend validates identity and entitlements, retrieves only eligible chunks, sends that context to the LLM, and returns a grounded answer with citations.

Salesforce Knowledge → publish/update event or scheduled sync ↓ Integration service / Azure Function ↓ extract → normalize → chunk → embed Azure AI Search (vectors + article metadata) Experience Cloud / Salesforce LWC ↓ authenticated question + trusted user context Secure API → entitlement filter → vector retrieval ↓ LLM → grounded answer + citations → chatbot

Keep ingestion separate from query processing. Index article ID, version, language, publication state, channel, audience and access metadata. Handle unpublishing, access changes, re-indexing, retries and deletion. Include encryption, least-privilege credentials, monitoring, prompt-injection defenses, cost and latency controls.

Architect point: Vector similarity is not authorization. Filter retrieval by entitlements before content reaches the LLM. Do not rely on a prompt telling the model to hide restricted content.

References:Azure AI Search vector searchMicrosoft RAG design guideSalesforce Knowledge developer guide

2. Is the knowledge base in Salesforce, with Azure doing the vectorization and an LLM handling queries? Is this for external users?

Answer

Yes, this is a common separation of responsibilities: Salesforce owns authoring, approval and publishing; Azure handles ingestion, chunking, embeddings, vector retrieval and orchestration; the LLM generates an answer from retrieved context. The same design can serve employees, authenticated Experience Cloud users or other channels. Each channel needs an explicit identity and authorization model.

For external users, classify content as public, authenticated-user, partner, account-specific or otherwise restricted. Derive entitlements from a trusted server-side identity, not from a persona string supplied by the browser.

References:Experience Cloud overviewAzure AI Search filters

3. How are external users authenticated? Would a partner need Salesforce access or a particular license?

Answer

If the chatbot is hosted in Experience Cloud, external users generally authenticate through the site with an external-user license that supports the required features. Partner users are typically associated with an Account and Contact and provisioned as partner users. Public content may be exposed without login, but private or partner-specific content requires authentication and authorization.

Choose the license after mapping required objects, sharing, roles, partner relationship features, API needs and expected user volume. External identity provider sign-in can authenticate the person, but it does not automatically provision a partner user or grant article access.

References:Partner usersSocial sign-onExternal identity licenses

4. Which chatbot technology are you using?

Answer

Be precise about the actual implementation. For example: “The UI is a custom Lightning Web Component. It calls a secured backend for retrieval and answer generation. Azure AI Search provides vector retrieval and the selected Azure-hosted model generates the response.” If using Agentforce, Einstein Bots, Copilot Studio or another product, name it only if it is genuinely part of the solution.

Explain which component owns conversation state, authentication, retrieval, prompt construction, safety checks and telemetry.

References:Lightning Web ComponentsAzure OpenAI overview

5. If users are authenticated, how does the chat identify their persona and ensure they only get knowledge articles they’re authorized to see?

Answer

The backend must derive identity from a validated session or token. Map the authenticated user to trusted attributes such as Salesforce user ID, account/contact, permission assignments, audience, region or entitlement records. Index corresponding article metadata, then apply a server-side allow-list or filter before retrieval. For sensitive content, re-check access against Salesforce before returning the final answer.

Do not trust account IDs, persona names or article IDs supplied by client JavaScript. Log the identity, retrieved article IDs and policy decision without retaining unnecessary sensitive prompt data.

References:Knowledge in Experience CloudAzure Search filters

6. How does the chat receive information about the authenticated user and determine which articles that user can query?

Answer

The LWC calls Apex or a trusted backend in the authenticated Salesforce context. Apex can obtain the current user ID using UserInfo.getUserId() and resolve permitted attributes server-side. Pass a short-lived signed identity assertion or server-resolved entitlement scope to Azure. Azure validates issuer, audience, signature, expiry and claims before filtering the index.

Do not use a Salesforce session ID as a general-purpose credential for an external service. Define token lifetime, signing-key rotation, claim mapping and how entitlement changes or revocation reach the index.

References:Apex UserInfoMicrosoft access tokens

2. Salesforce-Azure integration and OAuth

Be able to describe both the callout mechanics and the operational design around it.

7. How are you pushing new Salesforce Knowledge content into Azure?

Answer

Use reliable change detection. On publish/update, Salesforce can publish a platform event or invoke an integration process; alternatively, a scheduled process queries articles changed since a saved watermark. The integration retrieves approved body content and metadata, transforms and chunks it, creates embeddings and upserts chunks using a stable key such as article ID + version + chunk number.

Make processing idempotent. Track source version and sync status, retry transient failures with backoff, route poison messages to a dead-letter queue, and remove or update indexed chunks when an article is unpublished or its audience changes. Keep indexing asynchronous so publishing does not wait for embedding.

References:Salesforce Pub/Sub APICompeting consumers pattern

8. How are Salesforce and Azure authenticated to each other?

Answer

Use dedicated integration identities and OAuth-based trust. For Salesforce calling Azure, configure a Named Credential and External Credential with an appropriate OAuth flow, such as client credentials when supported by the target API. Register an application in Microsoft Entra ID, grant minimum API permissions, and configure token endpoint, scope/audience and secure credential storage.

For Azure calling Salesforce, configure a Salesforce connected/external client app and an appropriate OAuth flow, often JWT bearer for server-to-server use with a certificate. Avoid shared passwords and hard-coded secrets. Rotate credentials and separate identities by environment.

References:Salesforce Named CredentialsOAuth client credentialsCertificate credentials

9. What integration pattern are you following?

Answer

Name the pattern for each flow. Knowledge publishing is asynchronous, event-driven content replication. A chatbot question is synchronous request-reply because the user waits for an answer. Indexing is decoupled from the user transaction. One solution can use multiple patterns. Explain direction, trigger, payload, response expectation, consistency, retries and error ownership.

References:Salesforce integration patterns

10. In a new project, how would you explain to an Enterprise Architecture Review Board how Salesforce authenticates with Azure and what integration pattern is used?

Answer

Present context and sequence diagrams. Identify Salesforce as client, Azure API as resource server and Entra ID as authorization server. Explain the Named/External Credential boundary, OAuth grant, token audience/scope, TLS, certificate or secret storage, least-privilege permissions and rotation.

Classify each flow as request-reply, event notification, batch sync or fire-and-forget. Include payload contract, idempotency, timeout, retry/backoff, dead-letter handling, monitoring, data classification, network controls, operational ownership and behavior during Azure outages.

References:Salesforce integration patternsEvent-driven architecture

11. How does Azure know that a POST callout is legitimate and came from Salesforce?

Answer

Azure should validate an access token from a trusted identity provider, not trust the POST method, a custom header or source IP alone. Salesforce obtains a token through the configured OAuth flow and sends it over TLS. Azure validates signature, issuer, audience, expiry and required roles/scopes, then authorizes the operation.

Certificate-based client authentication, API Management policies, network restrictions, rate limiting and correlation IDs can add defense in depth. A valid token does not make arbitrary payload values trustworthy.

References:Access token conceptsAPI Management access restrictions

12. What integration patterns are available for two systems to communicate? Besides Request-Reply, what other patterns can you name?

Answer

• Request-Reply: caller waits for response.
• Fire-and-Forget: caller sends work without waiting for business completion.
• Batch synchronization: scheduled bulk movement.
• Remote Call-In: an external system calls Salesforce.
• Data virtualization: access remote data without copying it into Salesforce.
• Event-driven publish/subscribe: producers publish events for independent consumers.
• Streaming / Change Data Capture: consumers receive change notifications.
• Orchestration: a central workflow coordinates multiple services.

Choose based on latency, volume, coupling, consistency, reliability and whether an immediate result is required.

References:Salesforce integration patterns

13. Can you explain the basic OAuth workflow and how two systems securely establish a connection?

Answer

OAuth 2.0 is an authorization framework. A client obtains an access token from an authorization server and presents it to a resource API. The API validates the token and enforces its permissions. In delegated user flows, the user authenticates and authorizes access; in machine-to-machine flows, the application authenticates as itself.

1. Register the client and define redirect URIs, scopes or application roles.
2. Request authorization or a token using the selected grant.
3. The authorization server authenticates the user/client and issues a token.
4. The client calls the API over TLS with the token.
5. The API validates token claims and authorizes the operation.

Use Authorization Code with PKCE for interactive sign-in where appropriate, and Client Credentials for confidential service-to-service clients. OAuth access tokens are not necessarily JWTs; treat them as opaque unless the provider contract says otherwise.

References:OAuth 2.0 RFC 6749PKCE RFC 7636Authorization code flow

14. What’s the difference between an Authorization Code and an Access Token?

Answer

An authorization code is a short-lived, one-time value returned after the user authorizes a request. The client exchanges it at the token endpoint, using PKCE and client authentication as applicable, to obtain tokens. It is not used to call the API.

An access token is presented to the resource API to access protected resources. It has an audience, permissions and lifetime. Protect both values and avoid logging them.

References:Authorization Code GrantAccess token definition

15. How would you design a Fire-and-Forget integration that sends an order and its order lines to an ERP? What would you tell a developer to build?

Answer

Confirm eventual consistency is acceptable and define how failures are surfaced. On order submission, validate and persist the order, then publish an event or enqueue a durable message after commit. Middleware consumes it, maps the order and lines to the ERP contract and sends it using OAuth.

• Stable external order ID and idempotency key to prevent duplicate ERP orders.
• Versioned JSON schema and validation of required fields, currency, tax and line rules.
• Durable queue/outbox or event delivery so messages are not lost.
• Exponential backoff for transient errors; dead-letter/manual replay for permanent errors.
• Correlation ID, structured logs, dashboards and alerts.
• ERP acknowledgement/status callback or reconciliation job.
• Named Credential, least-privilege identity, TLS and no secrets in code.

Fire-and-forget means the initiating transaction does not wait; it does not mean ignoring failures.

References:Salesforce integration patternsQueue-based processing

3. Data loading and migration

Cover API selection, volume, data quality, external IDs, relationships, duplicates and reconciliation.

16. Have you done data loading yourself?

Answer framework

Give a truthful example and quantify the source, objects and record volume. Explain the tool/API, transformations, relationship handling, validation and reconciliation. Mention Data Import Wizard, Data Loader, REST API, Bulk API 2.0, middleware or ETL as applicable.

A strong answer covers external IDs for upsert, parent-before-child sequencing, lookup resolution, picklist mapping, duplicate rules, error-file handling, retry/reload strategy and record-count reconciliation. Distinguish hands-on work from work you designed or supervised.

References:Bulk API 2.0Data Loader

17. What is Data Skew in Salesforce?

Answer

Data skew is an uneven concentration of records or relationships that can cause contention and performance issues. Common forms include ownership skew (many records owned by one user), account data skew (many child records under one Account) and lookup skew (many records reference the same lookup target). These patterns can increase locking contention during updates and integrations.

Mitigate by distributing ownership where appropriate, designing parent-child relationships carefully, controlling batch parallelism, ordering updates to reduce lock collisions and monitoring lock errors. Do not change ownership without checking sharing and business impact.

References:Salesforce: reducing account data skewAvoid account data skew

18. Which API would you use for data loading?

Answer

• Data Import Wizard: guided imports for supported objects and smaller jobs.
• Data Loader: desktop bulk import, export, update, delete and upsert.
• Bulk API 2.0: asynchronous large-volume load/query jobs.
• REST API: smaller or near-real-time integrations.
• Composite API: group related REST operations and reduce round trips.
• SOAP API: established integrations requiring its contract/operations.

Choose based on volume, latency, transaction needs and API limits. For migration, plan external IDs, dependency order, parallelism, lock contention, retries and reconciliation.

References:Bulk API 2.0REST APIComposite API

19. Have you worked on a migration project from one system to another?

Answer framework

Explain discovery and source profiling; target model mapping; cleansing and transformation; external ID strategy; dependency/load sequencing; trial migrations; validation and reconciliation; cutover; delta migration; rollback and post-go-live support.

Also cover privacy, retention, auditability, downtime window, throughput, API limits, sharing recalculation and stakeholder sign-off. Give a real example and state your personal role.

References:Salesforce Architect resourcesBulk API 2.0

20. What data were you syncing from Marketo to Salesforce?

Answer framework

Describe the actual objects and fields in your project. A typical sync may include leads/contacts, email and phone, company/account attributes, lead source, lifecycle status, campaign/program engagement and consent preferences, depending on integration scope.

Explain field ownership and sync direction: which system is authoritative for each field, conflict resolution, unsubscribe/delete handling, timestamps/watermarks, error replay and monitoring. Do not imply every Marketo activity is automatically copied to Salesforce.

References:Adobe Marketo Salesforce sync

21. If duplicate leads arrive from Marketo, where would you put the restriction to prevent duplicate records in Salesforce?

Answer

Use layered prevention. Define a reliable matching key, such as normalized email plus additional business attributes where appropriate. Configure Salesforce Matching Rules and Duplicate Rules to alert or block based on policy. For integration loads, use upsert with a stable unique External ID from the source where possible.

A pre-insert query alone is not concurrency-safe because two requests can pass the check simultaneously. A unique field constraint is stronger when the business key is genuinely unique. Define behavior for shared email addresses, converted leads and records from other channels.

References:Salesforce Duplicate ManagementExternal ID fields

4. SSO, Experience Cloud and Salesforce security

Separate authentication, provisioning, object permissions, record sharing and Knowledge/article access.

22. What’s the difference between SP-Initiated and IdP-Initiated SSO, including the user experience?

Answer

In SP-initiated SSO, the user starts at Salesforce or the target application. Salesforce redirects the user to the identity provider with an authentication request. After login, the IdP posts a SAML response to Salesforce, which validates it and creates the session.

In IdP-initiated SSO, the user signs in to the IdP portal and clicks the Salesforce tile. The IdP sends an unsolicited SAML response to Salesforce. SP-initiated flows provide explicit request correlation and relay-state context; IdP-initiated can be convenient through an app launcher but requires careful validation and configuration.

References:Salesforce SAML SSOIdP-initiated login

23. Have you worked with partner portals or Experience Cloud?

Answer framework

Describe the actual site, user audience, external-user license, login method, Account/Contact relationship, permission sets, sharing sets/roles, page access, Apex/LWC exposure and Knowledge visibility. Be clear about what you personally configured versus what another team owned.

Architect-level coverage includes guest-user restrictions, least privilege, secure Apex, CRUD/FLS enforcement, record sharing, session policies, user lifecycle and monitoring.

References:Experience Cloud overviewApex security

24. How would you configure partner login using LinkedIn or Google accounts?

Answer

Register the application with the identity provider and configure the supported Salesforce Auth Provider/social sign-on settings. Set client ID/secret, authorization and token endpoints, scopes, callback URL and user-info mapping. Expose the provider on the Experience Cloud login page, test the callback and map the external identity to the correct Salesforce user.

Use a stable provider subject identifier rather than email alone to link identities safely. Define pre-provisioning or just-in-time provisioning, account linking, MFA, deprovisioning and recovery. Social login authenticates a person; it does not automatically create a partner user or grant partner permissions. Confirm current provider and Salesforce support before implementation.

References:Configure Auth ProviderExperience Cloud social sign-onGoogle OpenID ConnectLinkedIn authorization code flow

25. How would you configure SSO?

Answer

First confirm protocol and trust direction. For SAML, exchange metadata/certificates and configure entity ID, ACS URL, SSO URL, issuer, certificate, NameID and attribute mapping. Map the assertion to a Salesforce user using a stable identifier such as Federation ID. Test login/logout and plan certificate rotation.

For OIDC, configure the appropriate Auth Provider or connected application, redirect URIs and scopes; validate issuer, audience and nonce and map identity claims. Also address provisioning, MFA, session timeout, My Domain and break-glass administrator access.

References:SAML SSO setupAuth Provider setupOpenID Connect Core

26. If an object’s Organization-Wide Default is Private, can someone higher than the record owner in the role hierarchy see the record?

Answer

Generally yes for standard objects: role hierarchy grants access to records owned by or shared with users below the viewer. For custom objects, “Grant Access Using Hierarchies” can be disabled where supported, so hierarchy access is not automatically granted. Object-level Read permission is still required; sharing does not grant object permissions.

State assumptions and verify the setting on the specific custom object and org configuration.

References:OWD and sharing settingsSharing rules

27. How can access to records on a private object be opened up?

Answer

Keep OWD Private as the baseline and grant access selectively through role hierarchy (where enabled), owner-based or criteria-based sharing rules, public groups, manual/team sharing where supported, Apex managed sharing or territory management for supported use cases.

Remember the two layers: profiles/permission sets grant object-level Read/Edit; sharing grants record-level access. Users need both. Prefer declarative sharing for stable simple rules and Apex managed sharing for dynamic or complex requirements. Reassess access after ownership or criteria changes.

References:Sharing rulesApex managed sharingPublic groups

28. For a global Salesforce system, how would you configure a private custom object so country leaders can view records and only the appropriate country security users can modify them?

Answer

Set OWD to Private and deliberately decide whether hierarchy access should be enabled. Add a controlled Country field or country reference to each record. Create governed public groups for each country’s leadership audience and security users.

Use criteria-based sharing rules to grant Read Only access to that country’s leadership group for records where Country matches. Grant Read/Write to the country security group only if every member should edit all records for that country. For more complex conditions, use Apex managed sharing or a governed assignment process. Use permission sets to provide object-level Read/Edit permissions, then share only the required records.

Critical distinction: Sharing rules grant access; they do not remove access. Check owner access, role hierarchy, Modify All, View All, broad groups and Apex sharing. Test cross-country isolation, users in multiple countries, ownership changes and negative cases proving one country’s users cannot edit another country’s records.

References:OWDCriteria-based sharingPublic groupsApex managed sharing

Architect answer checklist

• Requirements: user types, volume, latency, availability, sensitivity and compliance.
• Trust boundaries: who authenticates whom, token audience, scopes, certificates and secret rotation.
• Authorization: object permissions, field access, record sharing and content entitlements.
• Reliability: retries, idempotency, dead-letter handling, replay and reconciliation.
• Scale: API limits, bulk processing, data skew, locking, caching and rate limits.
• Operations: correlation IDs, logs, dashboards, alerts, runbooks and support ownership.
• Trade-offs: explain why you chose a pattern and what limitations it introduces.