The Architect Framework for Every Salesforce Implementation
The Salesforce Certified Technical Architect (CTA) is the pinnacle of all Salesforce certifications. Where all other certifications can be passed through sheer brute force memorisation or luck, the CTA certification requires passing a pressure test environment with a live presentation to a panel of Salesforce architects at their peak, followed by rapid fire questions that you can only pass if you can provide clear AND concise responses on the spot that can satisfy to the judges that you have mastered your craft.
The CTA board exam is tough because of the time limit given to comprehensively solve a complex customer scenario that would typically take weeks if not months to tackle if it were to be in a real world situation. The same thought process and Architect framework for the CTA board, however, can be readily applied to any customer engagement. Regardless of whether you are new to Salesforce, a seasoned consultant, or preparing for your CTA board, using this to frame your architecture will make you a better Salesforce practitioner, avoid a lot of embarrassment and heartaches, and ultimately reduce the risk of customer failures and attrition.
There are no secrets to be found here. Everything I have written is freely available in trailhead, the success community, other blogs, etc. It is putting all this together and presenting the whole picture that is critical to success. The experiences I draw on are from the perspective of real customer engagements and written in the context of applying this framework and mindset in the real world. This is not intended as a guide for passing the CTA board (I may write about that in the future!). As with anything, practice, seek quality experiences, and adopt a continuous learning mindset to enable you to be a better architect.
1. System Architecture
The very first fundamental is defining the system landscape with all the systems and platforms that Salesforce will be interacting with. Salesforce is never acting in isolation. Even in my smallest non-profit pro bono work, admins still periodically manually load data to Salesforce from other sources or extract data to perform functions externally in excel.
Determine which capabilities will exist within Salesforce (on platform) vs outside of Salesforce (off platform). Salesforce is a platform that comes with a plethora of out of the box capabilities and flexibility to customise it to do just about anything. However, just because you can doesn’t mean you should. As a Salesforce architect, you need to understand the limitations and constraints of the platform to advise the customer and recommend the optimal approach.
Key considerations:
- Org strategy: Will this be a single org or will a multi org architecture better suited? Learn the challenges between the two and understand the tradeoffs that need to be made.
- Reports & Analytics: Will the out of the box reports & dashboards be sufficient? Understand up front if you will need Einstein Analytics (additional license costs) and / or integration to off platform Business Intelligence tools.
- Mobile: Is the Salesforce mobile app sufficient? Will a more branded and custom mobile app be needed for customers and partners? Will Mobile Publisher (additional costs) be used or a complete custom build with Salesforce Mobile SDK.
- Users & Licensing: Who are the users and what license requirements do they need? In most cases, the licensing has already been purchased upfront so this is rarely something that architects will have influence over. However, it is still useful to review all the users / actors and whether anything has been missed or a lower (cheaper) license will suffice for particular groups of users.
- Storage Limits: What is the document storage sizing requirements? Verify if the included file storage allocations will meet projected use cases or if external storage solutions will be required, especially for large videos.
- External Access: How will your customers, partners, agents, dealers, distributors access their data? Will you use a community or will you create a bespoke portal and integrate into Salesforce.
- Scale & Performance: Will the platform scale to meet your needs? Understand the limits of the platform and architect to those constraints.
2. Security
Security is one of the most complex areas to understand in detail but arguable the most important consideration for any Software as a Service (SAAS). Data access configuration in Salesforce is additive so any extra configuration will only open up access for the records. Ensure that your design takes all the users into consideration. Opening up access to one group has the potential to incorrectly open up access to other users if not implemented and tested adequately. This is especially significant when extending access to external users (customers, partners, unauthenticated guess users). Loss or breach of customer data can be detrimental to a company’s brand and reputation.
Key considerations:
- Event Monitoring: Monitor for suspicious activities and proactively react to transaction level security events to mitigate against threats
- Auditing & Logging: Enable field history tracking and change data capture, or build custom rules around privacy logging and reporting.
- Platform Encryption: If data encryption at rest is a mandatory requirement, be aware of the constraints that field level encryption places on platform behaviour. Encrypt only what is necessary and consider whether alternate factors of authorisation and security are sufficient enough to mitigate against the risks and concerns. If your instance is in AWS, it will have encrypted Elastic Block Store (EBS), meaning the entire volume is already encrypted by default.
- File Security: Salesforce does not scan files for virus or malware. Understand how files are treated and how users can protect themselves against this risk.
- Identity: Which system will act as the identity provider? Will social sign on be required? Will external users be able to self register? Will the same identity be shared across platforms?
- API & Integration Access: Enable API access only for users that require it. Follow the principles of least privilege and restrict the authorisation to only what is necessary. Secure the integration with mutually authenticated SSL for system to system access.
- Org Wide Defaults: Choose the org wide defaults that fit your organisation for both internal and external users. Many times it may sound ‘nicer’ to default a private restricted access model to all records but it increases the complexity of the sharing model when there might not be valid reason to this. Eg. In a case where all internal users can see all the same account data in SAP, why does that data need to be additionally restricted in Salesforce?
- Guest User Access: Did you know unauthenticated users to a community have their own “guest” profile? Lock down the guest user’s access to objects, classes, and APIs.
- Sharing & Visibility: Role Hierarchy, Sharing Rules, Sharing Sets, Account Relationship Data Sharing Rules, Territories, Manual Sharing, etc., etc., The combinations of these can get complicated very fast. Design this upfront and understand all the mechanisms that drive record level visibility and the limitations that will require programmatic solutions instead.
3. Data
Designing a sound data architecture will make or break the entire solution. Employing a suboptimal data model can result in extensive rework when gaps are realised later in phases of the project. Learn all the standard objects and when to / when not to employ them. When to use an opportunity instead of a case, a case instead of an order, a lead instead of an account. These decisions will either allow you maximise the inbuilt capabilities around these special standard objects or on the other extreme… constrain you to their limitations.
Key considerations:
- Data Volumes: Extrapolate and project all volumetrics for data in every object. This is especially important for child or junction objects that can quickly grow exponentially. Data volumes are generally considered large when they exceed the ability for Salesforce to use selective indexes for queries.
- Standard vs Custom Objects: Use standard objects where appropriate and choose the right object for the right use case. When is an enquiry considered a lead? When is a similar enquiry considered an opportunity? When is it a case instead? Create custom objects where there is no obvious match.
- Custom Metadata Types: Reference data should be stored as custom metadata types. This enables this type of data to be versioned as code and deployable as part of the metadata API.
- Data Virtualisation: Data storage in Salesforce is relatively expensive and too much can cause performance issues. Avoid putting data on platform for the sake of just having data. Will this data be referenced? Will it be used in any manual or automated processes? Can it be virtualised and accessed just in time via integration? Exposed as a UI mashup?
- Data Quality: The old adage of “garbage in, garbage out” applies here. Lack of data quality degrades trust and value in the platform. Train users to maintain good account hygiene, leverage data deduplication & merge rules, introduce validation where appropriate and automated processes to help data entry and maintenance.
- Data Migration: How will you transfer all the data from legacy systems over to Salesforce for go-live? Will there be a clean cut over or a phased migration? Will the other systems remain in read only mode, continue to be live, or shut down from immediately? How will you translate and cleanse the data? Will you import all historical data or only what is current?
- Data Archiving: As data grows in Salesforce to millions of records, it is important to have a strategy to move this data off for historical auditing purposes, maintain performance of the platform, and keep data storage costs within limits.
- Data Backup & Restore: It is a common misconception that because the data is in the cloud, it is safely stored and there is no risk of data loss. Salesforce does perform restores of data corruption or data loss if it is a result of user errors (eg. a disgruntled sales manager, or an accidental mass data load).
- Data Masking / Obfuscation: The benefit of full copy sandboxes and partial copy sandboxes is they are instantiated with data for testing. The problem with this though, is that real production data becomes assessable to all testers and developers. In the majority of cases, customer data can not be used for testing as that was not the intended purpose customers originally agreed to. The lack of auditing, monitoring, and security in lower test environments expose this production data to unmitigated privacy and security risks.
- Ownership Data Skew. Avoid having more than 10,000 records owned by a single user (eg. assigning all external community users to be owned by a common internal user)
- Record Data Skew: Avoid having more than 10,000 child records against a parent.
4. Solution Architecture
In many ways, this is the crux of the architecture that delivers the solutions to the business needs of the platform. Knowing the platform’s capabilities and keeping up to date with every Salesforce release (3 times a year, every year!) is key to nailing this. You can’t design something you don’t know and this may lead you to resorting to more complex programmatic solutions when out of the box configurations exists.
Key considerations:
- Build vs Buy: Take a declarative first approach. If there is no configuration available, look for mature app exchange solutions. Finally, custom build as a last resort. There are some exceptions to this.
- Internal vs External Capability: In many cases, unless the capability is closely related to Salesforce functionality (eg. extending opportunities), it is easier and more extensible to build custom capabilities off platform, especially if it is Heroku with Salesforce data auto-sync’d bidirectionally via Heroku connect.
- Business Process Design: Reimagine business processes into how they would be best done in Salesforce. Avoid lift and shift. Know the out of the box features that can be easily turned on to maximise business benefit of what the customer has paid for.
- Configuration vs Customisation: Whilst configuration is almost always preferred, some level of customisation is always needed in every implementation. This is because Salesforce is built as a platform to meet the general needs of the wide range of businesses so there will always be specific functionality that is required to be customised for a specific niche. Where customisations in other platforms I’ve worked with, impeded upgradability, this is not the case with Salesforce. Being able to almost infinitely customise as much as it can is arguably the real power of platform.
5. Integration
Integration is perhaps the most technical domain of Salesforce. It is tech talking to tech, complex sequence diagrams, translations, error handling, balancing limitations and tradeoffs, and knowing which of the many integration toolkits and patterns to use. The Salesforce integration best practices guide is your best friend. Even though this is a complex domain, the simplicity is that there are only so many ways you can integrate with Salesforce. APIs, web services, outbound messages, platform events, Salesforce connect, Files connect, canvas, etc. It may seem daunting at first but once you build your repertoire it becomes easier and easier to recognise the patterns. Rinse and repeat.
Key considerations:
- Integration Patterns: Sync vs Async. Platform Events vs Outbound Messaging. Batch vs Realtime. Data Virtualisation vs UI Mashups. Understand the pros / cons of each and when to employ which pattern.
- Security: Secure the data transferred between systems with IP whitelisting to limit connections to the known Salesforce IP ranges, oAuth JWT for system to system authentication , Mutually Authenticated SSL for encrypted data in transit. Consider per user authentication vs a single integration user.
- Salesforce Connect: Specific to External Objects with the odata interface, there is no support for record level security. Therefore anyone who has access to the object will be able to view all records regardless of which parent object the record may be related to. Use External Objects only where the data is okay to be visible to all internal and external users. Otherwise, implement custom record level authorisation at the end point, the middleware, or custom in Salesforce.
- Error handling: Build an error handling framework to log errors, enable automated and manual retries, and escalate alerts for critical failures.
- Volume and Throughput: Estimate the required volumes and peak throughput for each interface to ensure they will be within the governor limits as the organisation grows. This is especially important to take a whole of platform view when development is shared across many teams.
- Process Orchestration: Should orchestration be handled within Salesforce apex or pushed down to the middleware layer? It may be tempting to build orchestration within Salesforce but complex state logic and managing related integrations is not a core Salesforce capability. Whilst it is possible to do this, it will be difficult to debug, maintain and support.
6. Development Lifecycle and Deployment Planning
Optimise the delivery methodology and processes so that the team can focus on developing value and minimal time on operational tasks. Automate everything (as much as possible). Learn and understand the benefits of various methodologies so you can employ the right practices and adapt it for you project. Regardless of which delivery methodology, the same underlying considerations on managing project risks, moving code, environment management, and governance still apply.
Key considerations:
- Methodology: Agile or Waterfall? Iterative waterfall or ‘big bang’? LeSS, SAFe, Lean, Scrum, Kanban, or ‘spotify’? There is no one size fits all model and no company is exactly the same as another. A traditional waterfall company can not move to pure agile at the flick of a switch. Choose and experiment on the practices that will suit your organisation. Learn, adapt, and evolve.
- Governance: Will teams be fully autonomous or will decision making need to be controlled by a central authority? What level of documentation is required and where will they be kept up to date for collaboration? How will project risks be mitigated? What checkpoints or gates are in place for playbacks and reviews? How will funding decisions be made for the project? What is the escalation path for critical issues?
- Source control: Salesforce does not keep versions of the repository. Even if the organisation is simple, it is still prudent to, at a minimum, keep source code versioned in an external repository such as bitbucket or github.
- Development Model: Choose between Changeset development, Org development, or Package development model with Salesforce DX. Changesets are the easiest for simple projects. DX allows for flexible modular development for separate teams and separate release schedules.
- CI/CD: Continuous integration and continuous delivery is, relative to changesets, complex to setup but once it is in place the return on investment is invaluable for large programs. It is not uncommon to have teams spend weeks attempting to fix issues because the various branches of development were never merged and the deployment errors left too late to resolve.
- Environment Management: Depending on the Salesforce edition, Salesforce includes a limited number of full copy sandbox (only ONE is available for Performance and Unlimited Edition!), partial copy, developer pro, and developer sandboxes. Each sandbox type has various limits on data and refresh interval. It is important to define which sandbox will be allocated for which purpose and also align these to the external systems that they will need to integrated to. Development, Application Testing, Integration Testing, Business Acceptance Testing, Training, Hot Fixes, Innovation, Pre-Release. Ensure each sandbox on the critical release path is on the same Salesforce version (especially important during the pre-release windows!).
- Test Strategy: Define the test strategy for various different types of functional testing, regression testing, progression testing, integration testing, pre-release testing, penetration testing, load and volume testing. How will tests be automated? What test data needs to be available? What systems need to be integrated or end points stubbed? Have a plan for Salesforce pre-release testing during the pre-release windows for each of the three major releases a year. Remember, specifically for security and load testing, Salesforce support needs to be contacted and official approval gained weeks in advance.
7. Communication
The final piece of the Architect framework is communication. Ideas are great but if you can not communicate them effectively to others, they will just remain as ideas or wishful thinking. Knowing your stuff, grounding it with experience and practise will go a long way to being able to speak with authority and presence. Learn to handle objections, adapt and alter the solutions depending on the customer situation and be prepared to handle unexpected changes or roadblocks that might arise. No one is perfect. Practice psychological safety, learn and grow from the mistakes.
