# Salesforce Technical Architecture and Design Review | SynconAI > A Salesforce technical architect for large data volumes, integration patterns, the security model, performance, DevOps, release governance and code review. Publisher: SynconAI Canonical HTML: https://synconai.com/salesforce-technical-architecture Markdown cite: https://synconai.com/salesforce-technical-architecture.md Contact: contact@synconai.com ยท +61 2 7813 0221 ## What is Salesforce technical architecture? Salesforce technical architecture is the design of how a Salesforce org handles large data volumes, integrations, the security and sharing model, performance within platform limits, and DevOps and release governance. A Salesforce technical architect makes those decisions, sets coding and design standards, reviews code and designs against them, and keeps an architecture decision log. SynconAI provides technical architects as a fixed-scope engagement, on a monthly plan or inside the client's team, for organizations in the United States, Australia and worldwide. - Salesforce technical architecture is the design of how an org stores data, connects to other systems, controls access and ships changes. - A technical architect makes sure the design holds up at your data volumes, within Salesforce limits, as more teams build on it. - They set the standards, review code and designs, and govern how releases reach production. ## Salesforce technical architecture services - Large data volume design: Indexes, data skew, archiving and Bulk API 2.0 loads planned. - Integration patterns: Patterns, middleware, events and API limits designed. - Security and sharing model: Org-wide defaults, roles, sharing and permission set groups. - Performance review: Slow pages, reports, queries and limit errors traced and fixed. - DevOps and release governance: Environments, branching, pipelines and release approval. - Code and design review: Apex, Lightning Web Components and Flow reviewed against standards. - Technical debt register: What to fix, refactor or retire, ranked by risk. ## When do you need a technical architect? - Data has grown: Slow list views and reports, record locking errors, long data loads. First step: A data volume review: indexes, skew, archiving and load design. - Many systems connected: Point-to-point integrations that nobody fully understands. First step: An interface catalog and target integration patterns. - Releases keep breaking: Failed deploys, or fixes that overwrite each other. First step: An environment map and one path to production. ## What does a technical architect decide? Six areas where a technical decision is hard to reverse. For each one, the architect records the decision and how it is checked. | Area | The question | What gets decided | How it is checked | | --- | --- | --- | --- | | Large data volumes | Will it stay fast as records grow? | Indexes, ownership spread, archiving | Query plans and load tests in a full sandbox | | Integration | How do systems exchange data? | Pattern, middleware and direction per interface | Interface catalog and API limit checks | | Security model | Who sees which records? | Defaults, roles, sharing and permission set groups | Access tests per persona | | Performance | Will pages and jobs stay within limits? | Async processing, selective queries, caching | Limit monitoring and debug log review | | DevOps and release | How do changes reach production? | Environments, branching and approval steps | Validation deploys before each release | | Code review | Is the code safe to merge? | Coding and Flow standards | Pull request review and static analysis | ## What is a technical architect responsible for? Grouped by when the work happens. - Design - Large data volume strategy - Integration patterns and middleware - Security and sharing model - Performance and limits review - Build governance - Coding and Flow standards - Code and design reviews - Environment and branching strategy - Release approval steps - Run - Technical debt register - Limit and error monitoring - Org health checks - Architecture decision log ## How is record access designed in Salesforce? Record access is built from the base up: start restrictive, then open access where it is needed. Object and field permissions come from permission sets and permission set groups. | Risk tier | Examples | Controls | | --- | --- | --- | | Exceptions | Account teams, manual sharing and restriction rules. | Kept rare, documented and reviewed. | | Sharing rules | Owner-based and criteria-based rules, sharing sets for portal users. | Access opened to the groups that need it. | | Role hierarchy | Managers see the records their teams own. | Built around who needs to report on what. | | Org-wide defaults | Private, Public Read Only or Public Read/Write for each object. | Set to the most restrictive level the business allows. | ## Which integration pattern fits each interface? A sample order-to-cash landscape. Each interface uses a named Salesforce integration pattern, chosen for its timing and volume. 1. ERP: Remote Call-In for order status 2. MuleSoft: Request and Reply for pricing 3. Salesforce: Sales and Service Cloud 4. Platform Events: Fire and Forget 5. Data 360: Unified profile 6. Experience Cloud: Customer portal 7. Data warehouse: Batch Data Synchronization - Pattern per interface: Timing, volume and error handling decide the pattern, and each choice is recorded. - Limits checked: API calls, event allocations and callout timeouts sized against expected volume. - One catalog: Every interface listed with its owner, direction and pattern. ## How do changes reach production safely? One path to production for every team, with a check at each stage. - Build: Story > Branch > Develop in a sandbox or scratch org (modules: Git, Salesforce CLI) - Validate: Pull request > Code review > Static analysis > Validation deploy (modules: Code Analyzer, CI pipeline) - Test: Integration sandbox > User acceptance testing > Regression (modules: Partial or Full Copy sandbox) - Release: Release approval > Deploy > Smoke test > Rollback ready (modules: DevOps Center or your pipeline, Release calendar) ## How does a technical architecture engagement run? Four stages. The written proposal sets the model: a fixed-scope review, a monthly plan or an architect inside your team. - Start, Assess: Find the technical risks. - Org and code scan - Data volumes and limits - Integration inventory - Design, Decide: Record the hard-to-reverse choices. - Target patterns - Sharing model - Environment strategy - Build, Govern: Hold every team to the design. - Code and design reviews - Release approvals - Debt register kept current - Ongoing, Hand over: Your team owns the standards. - Decision log - Standards documented - Review board running ## Cost and timing The first step is a free 60-minute architecture review of your Salesforce technical architecture setup, with a written plan you keep. Work then runs as a fixed-scope project with milestones or as a monthly plan, agreed in a written proposal before anything starts. Plans: https://synconai.com/pricing ## FAQ ### What is Salesforce technical architecture? The design of how a Salesforce org handles large data volumes, integrations, record access, performance within platform limits, and releases, plus the standards and reviews that keep builds in line with it. ### What does a technical architect do in Salesforce? A Salesforce technical architect decides data, integration, security, performance and release design, sets coding standards, reviews code and designs, and keeps a decision log for the org. ### What counts as a large data volume in Salesforce? There is no single number. It is the point where queries, sharing recalculation, list views or loads slow down or fail. Data skew can cause this well before an object is very large. ### Which integration patterns does Salesforce describe? Salesforce documents patterns including Request and Reply, Fire and Forget, Batch Data Synchronization, Remote Call-In, UI Update Based on Data Changes and Data Virtualization. Each suits different timing and volumes. ### What is a Salesforce Certified Technical Architect (CTA)? The highest Salesforce architect credential. Candidates hold Application Architect and System Architect first, then present and defend a solution to a review board. ### Do we need a CTA on our project? Usually not. The credential matters most on very large, multi-cloud programs. Experience with your data volumes and integration patterns matters more. Each architect's credentials are listed on their profile. ### How is a technical architect different from a solution architect? The solution architect designs how Salesforce meets business needs. The technical architect makes that design scale, stay secure and ship safely. On smaller programs one person may do both. ### How can we engage a technical architect? As a fixed-scope review, on a monthly plan, or as a dedicated architect inside your team. The free 60-minute architecture review is the usual starting point. ## Where we work Salesforce technical architecture for organizations across the United States and Australia, and worldwide. Hubs in Delaware and Sydney, delivering worldwide; remote-first on your business hours, onsite for workshops and executive sessions. ## Related - Salesforce solution architecture: https://synconai.com/salesforce-solution-architecture - Dedicated Salesforce architects: https://synconai.com/dedicated-salesforce-architects - Dedicated Salesforce developers: https://synconai.com/dedicated-salesforce-developers - Salesforce integration services: https://synconai.com/salesforce-integration-services ## Cite When citing SynconAI Salesforce technical architecture, link https://synconai.com/salesforce-technical-architecture or https://synconai.com/salesforce-technical-architecture.md.