Purpose of Artifacts
As part of the CTA review board, a candidate must create an end-to-end solution and communicate it to the judges. And as we all know a picture (diagram) is worth a thousand words, so having a set of artifacts that can help you engagingly tell the story while outlining the specifics and nuances of your solution is key.
The artifacts should be constructed with your presentation in mind and with the perspective of presenting your solution in front of executives or architects from the company in your scenario, who have a solid technical understanding of the Salesforce platform and are interested in getting your solution for the problems in the scenario.
What kind of Artifacts and Why?
When artifacts are used effectively in presenting your solution, they can cover your scenario's non-functional requirements and support your functional requirements. Each artifact (depending on the artifact) has a single purpose but can support multiple sections of your solution in the scenario.
A few artifacts are going to be required for your solution presentation, these include Actors and Licenses, Data Model Diagram, System Landscape, Role Hierarchy and Environment and Development strategy. While some others might not be required but add value depending on your scenario, these include Migration Strategy, Governance structure, and SSO flow(s). Including any other diagrams is not advisable given the time constraints and possibility of adding any feasible value to the solution.
In this article, I will cover the non-negotiable artifacts that should be part of your presentation which include Actors and Licenses, Data Model Diagram, System Landscape, Role Hierarchy and Environment and Development strategy. I may fast follow up with some of the other artifacts that might be beneficial in supporting other solution requirements which include Migration Strategy, Governance structure, and SSO flow(s).
Actors and Licenses
This is one of the foundational artifacts for your solution. With this artifact the following objectives should be met:
Key use cases for the actors identified in the scenario
Licenses (Including feature add-ons and third-party licenses) - Community licenses should be given extra scrutiny and the principle of least privilege should also be applied to licenses. Example: If you have a use case where a user is required to create a work order, giving them a Field Service Lightning license will be overkill.
Login mechanism (SSO or Salesforce login (MFA, Passwordless, etc))
This doesn't need to be an actual diagram and a table with relevant information should suffice for the solution. Below is an example of the Laptop to Schools scenario. I specifically chose this scenario as it has most personas and gives a good flavour of all the license types and use cases.
Actors | Licensing | Reason | Login |
Donation Coordinators | Sales Cloud | Accounts, Contacts, Oppty and Custom Objects | Federated SAML SSO |
IT Specialists | Sales Cloud | Accounts, Contacts, Oppty, Cases and Custom Objects | Federated SAML SSO |
Allocation Coordinators (School ACs and Recycling ACs) | Sales Cloud | Accounts, Contacts, Oppty, Cases and Custom Objects | Federated SAML SSO |
Managers | Sales Cloud | Accounts, Contacts, Oppty, Cases and Custom Objects | Federated SAML SSO |
Volunteers | Partner | Oppty Access | Social Sign On |
Virtual Experts | Service Cloud | Omnichannel Live Agent | Federated SAML SSO |
Corporate Users | Customer Community + | Custom Objects and Reporting | Salesforce Credentials (no specific requirement) |
Recyclers | Customer Community + | Custom Objects and Reporting | Salesforce Credentials (no specific requirement) |
Teachers/Students | Chatter Plus | Ideas and Answers | Social Sign On |
Data Model
Data model is the most crucial artifact of your solution as it supports and affects most sections of a scenario. Data Model should evolve with the different sections of the scenario and should be adjusted to the most optimal solution based on sharing and visibility requirements. The following information should be included in your data model:
Standard and Custom objects leveraged in your solution and their relationships. Key things to consider include:
Representation of customer entities (Households, Businesses etc). Usually, this is a combination of Account and Contact or a personal account.
Custom object limits for certain license types
Purpose-built standard objects and their use such as Opptys (Sales cycle, onboarding etc), Cases (Support), Leads (New Customers and qualification)
Relationships between objects should be selected with care according to your sharing and visibility requirements.
Organization-Wide Defaults (OWD) and Owners are also important aspects to be included in your Data Model as they support your sharing and visibility requirements. Key things to consider include:
The principle of Least Privilege states that OWD should be as restrictive as possible and should be opened using ownership, role hierarchy and sharing rules. There should be some thought put on the least privilege, as in some cases public read-only might be a good OWD for an object, especially knowledge articles.
Ownership should be carefully considered based on your sharing requirements and also LDV. Example: Ownership Skew can be avoided by having LDV objects system owned and sharing opened through OWD or wide sharing rules.
Large Data Volume objects should be identified and should address ownership skew if applicable and purging and archiving strategy if not master data (Account, Contact, Lead, Oppty).
The logical data model level (some people identify relationship fields but not necessary) is sufficient for the solution. Here is an example of a data model from the same Laptop to Schools scenario.
Disclaimer: Do not take the diagram as an optimal solution for the scenario but as a guide for the Data Model information that should be presented.
System Landscape
In most enterprise environments Salesforce is one of the systems that support complex business flows. To show the different systems and how they interact to guide the flow of data between with one another that is the purpose of the System Landscape. The diagram doesn't need to dive into the details of the integration interfaces but should identify the authentication and transit layer interface (REST, SOAP, Bulk API etc). The following information should be communicated through this diagram:
Show all on-premise (Credential Store, ERP, Business Specific Systems (Shipping and Inventory) etc), third party (AppExchange, Other Cloud Platforms, etc).
Systems that are going to be retired as part of your solution.
Integration interfaces including ESB and/or ETLs that support the flow of data.
SSO Federation services such as Okta or Ping.
Mobile Apps with brief descriptions of how they will be published or delivered.
Here is an example of a System Landscape from the Greenhouse Recycling Corporation scenario. I chose this scenario as this scenario has several systems and a few systems and functionalities that need to be retired.
Role Hierarchy
Several elements form the solution for the Sharing and Visibility requirements of your solution. Role Hierarchy is a crucial part of that solution and makes solutions for this section easier or worse depending on your approach. The following elements must be communicated through your role hierarchy:
Full role hierarchy of distinct branches of the hierarchy. Sometimes there will be common branches duplicated based on region or offices. These can be stated but do not need to be drawn.
Roles for external licenses and how they relate to the internal hierarchy if applicable (usually for partners).
In the example below from Green Roof Systems we have an office-specific hierarchy where installers have a hierarchy that rolls up through the channel manager (partner account owner) to management.
Environment and Development Strategy
The Environment and Development Strategy is a supporting artifact for your governance requirements. This artifact should be calibrated with the project requirements and governance framework in mind. This artifact should communicate the following information:
Environment matched to the development lifecycle, with environment types identified and justification.
Testing and if required migration activities planned for each environment.
Branching strategy tightly coupled with your environment strategy and key build automation identified
Governance if not specifically called out can be included in this artifact or as part of the presentation of the artifact.
The example below is of an Environment and Development Strategy for Greenhouse Recycling Corporation.
Conclusion
In this article, we deeply dive into the key artifacts required to be part of your solution. A thorough understanding of the Salesforce architecture domains is required to create and present these artifacts effectively. In the upcoming articles, we will dive deeper into these domains.
Resources
The following sources were leveraged to compile this article.
Comments