CTA - Things to Consider in Unison
I'm writing this article as the second of my CTA series, and I want to walk through some areas that you should really think about when doing the CTA exam and aspects that need to be though about in unison as their impact is wide reaching in the solution. I'm going to call out a few examples in this article to get people thinking and be switched on, on the day of the board.
(1) Data Model - Master-Detail or Lookup
The use of Master-Detail and Lookup fields has a very stern impact on the Sharing Model. 'Who can see what' suddenly is driven by a parent object and not the object in question itself. Whilst this may seem very trivial it can lead to the downfall for a lot of candidates, and it's something to keep in mind very closely. When doing the Data Model, consider the Sharing Implication hand in hand. If you have time do a sense check for what kind of objects and records the users in the system need to see, and does your sharing Model combined with your data model really support that. I'll write a separate article on the breakdown of CTA Sharing Model, but this is a starter for 10 to get you thinking in the right direction. For example if an object is a Detail object, you can't use Sharing Sets on that object, and this can therefore have an impact with what sharing approach you choose to use. Setting a Master to Public Read Only can result in all the detail records being Public Read Only as well, and we may or may not want that. Things to keep in mind.
(2) Choice of Users and Object Access
Certain Salesforce Licenses (Sales Cloud, Service Cloud, Salesforce Platform) only give access to certain objects. Perhaps one of your users needs access to a Lead or an Opportunity, but you had chosen earlier to give Platform Licenses to them - come back and update your Users and Licenses chart. Also in the review board you may need to change what primary objects you use, and this can impact your license choices - be mindful of this and make the required change on the Licenses sheet as well.
(3) Single vs Multi Org
There is a direct impact on the Role Hierarchy, whether a single or multi org setup is being used. If you are toying between single and mutli org in your solution, do remember that your sharing and Role Hierarchy no doubt will need to be updated accordingly, so keep this in mind when making that decision.
Also Large Data Volume numbers will change as the data volumes would now be split per org, rather than be overall. Thus objects that you felt were LDV in a Single Org scenario, may no longer be LDV in a multi org scenario.
(4) Governance
Deployment into a single org and multiple orgs, needs a proper understanding and a proper plan. If deployment is going into multi orgs - what model do we want to use? Hub and Spoke? Decentralised? How do we push changes into each org, or do we have each Production org manage their own stream of work - be prepared to advise on this if you are recommending a Multi Org approach - it's a good and valid question to be asked.
(5) Sharing Model - Owners, OWDs, OBS and CBS Rules
Make sure your sharing rule recommendations line up with your data model. A very neat trick is to very carefully choose the owners of each of your objects and leverage the Role Hierarchy to implicitly manage the sharing for you, and also help you use Owner Based Sharing rules to do so. This can solve some of your sharing concerns, challenges / requirements.
If you have time, I'd also advise sense check your sharing and see, do the people who need to see something have access to it, and who does it really make sense to share XYZ records with. Common sense thinking time will help you to be prepared for the questions that may come up on the board.
(6) Reporting
Please make sure that the data present for the reports is accessible to the users who need to see the reports via the sharing model :-). In a multi org scenario, make sure the data needed for reporting is being synched up to a Parent org if necessary.
So there's a couple of nuggets that i've picked up over time. Hope it is useful to all.
(1) Data Model - Master-Detail or Lookup
The use of Master-Detail and Lookup fields has a very stern impact on the Sharing Model. 'Who can see what' suddenly is driven by a parent object and not the object in question itself. Whilst this may seem very trivial it can lead to the downfall for a lot of candidates, and it's something to keep in mind very closely. When doing the Data Model, consider the Sharing Implication hand in hand. If you have time do a sense check for what kind of objects and records the users in the system need to see, and does your sharing Model combined with your data model really support that. I'll write a separate article on the breakdown of CTA Sharing Model, but this is a starter for 10 to get you thinking in the right direction. For example if an object is a Detail object, you can't use Sharing Sets on that object, and this can therefore have an impact with what sharing approach you choose to use. Setting a Master to Public Read Only can result in all the detail records being Public Read Only as well, and we may or may not want that. Things to keep in mind.
(2) Choice of Users and Object Access
Certain Salesforce Licenses (Sales Cloud, Service Cloud, Salesforce Platform) only give access to certain objects. Perhaps one of your users needs access to a Lead or an Opportunity, but you had chosen earlier to give Platform Licenses to them - come back and update your Users and Licenses chart. Also in the review board you may need to change what primary objects you use, and this can impact your license choices - be mindful of this and make the required change on the Licenses sheet as well.
(3) Single vs Multi Org
There is a direct impact on the Role Hierarchy, whether a single or multi org setup is being used. If you are toying between single and mutli org in your solution, do remember that your sharing and Role Hierarchy no doubt will need to be updated accordingly, so keep this in mind when making that decision.
Also Large Data Volume numbers will change as the data volumes would now be split per org, rather than be overall. Thus objects that you felt were LDV in a Single Org scenario, may no longer be LDV in a multi org scenario.
(4) Governance
Deployment into a single org and multiple orgs, needs a proper understanding and a proper plan. If deployment is going into multi orgs - what model do we want to use? Hub and Spoke? Decentralised? How do we push changes into each org, or do we have each Production org manage their own stream of work - be prepared to advise on this if you are recommending a Multi Org approach - it's a good and valid question to be asked.
(5) Sharing Model - Owners, OWDs, OBS and CBS Rules
Make sure your sharing rule recommendations line up with your data model. A very neat trick is to very carefully choose the owners of each of your objects and leverage the Role Hierarchy to implicitly manage the sharing for you, and also help you use Owner Based Sharing rules to do so. This can solve some of your sharing concerns, challenges / requirements.
If you have time, I'd also advise sense check your sharing and see, do the people who need to see something have access to it, and who does it really make sense to share XYZ records with. Common sense thinking time will help you to be prepared for the questions that may come up on the board.
(6) Reporting
Please make sure that the data present for the reports is accessible to the users who need to see the reports via the sharing model :-). In a multi org scenario, make sure the data needed for reporting is being synched up to a Parent org if necessary.
So there's a couple of nuggets that i've picked up over time. Hope it is useful to all.
This information so crazy, Thanks for sharing.
ReplyDeleteThis post is really nice and informative.
ReplyDeleteSales Force CPQ Online Training Hyderabad
Visit us: sales force CPQ Online Training
DumpsPass4Sure is the linchpin of success for Integration-Architect Exam Topics. Their precision and coverage make certification a breeze.
ReplyDelete