-
Notifications
You must be signed in to change notification settings - Fork 28
01) The Diagrams
When presenting your solution to the CTA Board there are five major diagrams that you must draw for your solution. They are listed below.
This diagram is used to communicate the required Salesforce feature and third party licenses for each user type and what the different user types will do in the system.
The purpose of this diagram is the following:
- This allows for an easy understanding of what each user type will be doing in the system and to easily justify their licenses.
- It is required to include all user types mentioned in the scenario, include all required license types (including feature and 3rd party).
- This should explain each users role in the system (what their primary function is ex: Sales User, Marketing User, etc). It should answer what these users are doing in the system.
Make sure to consider the following when creating your diagram:
- Include all actors/user groups mentioned in the scenario.
- Include all required licenses each actor will need. This includes standard, feature and third party licenses. Do not forget to include community actors and licenses and be careful with them.
- Use the best justified technical solution for these licenses, DO NOT try and cut costs.
- This should ideally be created using a standard "Actors and Use Cases" diagram, but can just be a bullet point list with the user types and a sub list with their activities to reduce the time spent on it.
Example Actors and Licenses Diagram (Need to create):
This Diagram is the MOST CRITICAL diagram to get right on the exam. Basically everything hinges on it. This is basically a simplified ERD.
The purpose of this diagram is the following:
- Identifies the custom versus standard objects used in your solution and your planned usage of each of them. Do NOT forget that some standard objects come with pre-built functionality (you need to know them in and out) AND DO NOT FORGET that certain licenses have both standard and custom object limitations. Do not forget about these when applying licenses to actors in your Actors and Licenses diagram or when designing here.
- To identify Large Data Volume Objects (LDV). You must make sure to label objects that are slated to house millions of records on your diagram.
- This should also highlight your sharing and visibility requirements. It is crucial to get these points across in this diagram. You need to label an objects OWD settings (Private, Read, Read/Write), whether or not there is a master detail relationship, and who the record owners will be.
- This data model should support your reporting strategy. It should help make it clear where reporting data is coming from.
- A solid ERD is key to producing a solid integration strategy.
This Diagram Must Include the Following:
- Relationship types (Master-Detail or Lookup)
- Cardinalities (one to many, many to many, etc)
- Object Type (Standard vs Custom vs External)
- OWD (Org Wide Defaults) for each object
- Mark LDV (Large Data Volume) objects and provide the math to justify it
- Record Ownership (Who is going to own the records of an object)
- Just showing the key fields on your ERD should be sufficient for the board, don't need to list every single one
Example Entity Relationship Diagram (ERD) (Need to create):
The system landscape diagram will help you illustrate the different systems included within your solution and their relationships with one another.
Example System Landscape Diagram (Need to create):
The system landscape diagram will help you illustrate the different systems included within your solution and their relationships with one another.
Example Role Hierarchy Diagram (Need to create):
The system landscape diagram will help you illustrate the different systems included within your solution and their relationships with one another.
Example Development Lifecycle Diagram (Need to create):