- SalesforceChaCha
- Posts
- π There Is No Try. Only Data. πΊ
π There Is No Try. Only Data. πΊ
Simple, High-Level Plan for Data Modeling
Good morning, Salesforce Nerds! Have you won that project and now have to actually deliver on the SOW? Maybe a little bit stressed over the part where it says you'll be leading the implementation effort for redesigning and/or optimizing the data model? Where do you even start? Especially if you're a noob in the client's industry? Try these high-level tips!

Agenda for today includes
Simple plan for data modeling
Daily Principle
All the Memes
Simple plan for data modeling
So, here you are. A fresh face leading a team of developers working in an org that's a teenager now. The state of things are ... not great. The org is plagued with issues. UNABLE_TO_LOCK_ROW, Apex CPU time limit exceeded. ALL. DAY. LONG. Good news is that the business understands a data model refactor is necessary. Bad news is that you have the lead in turning it from π© to π. Now what?!
Understand | The business requirements. You knew this was coming. This is the first step. And it's not always fun, but you won't get far without it. You need to know what kind of data is collected, how is it used, who or what is using it. Once you understand this, bump it up against the standard Salesforce data model. What requirements can you satisfy using OOTB functionality?
Secure | Ah, the 'S' word. You can't have an article about data modeling without bringing up security. But, that's just because you can't implement a data model in Salesforce without thinking through this. You need to consider who needs access to data and what level of access they need. Use OOTB features like profiles, roles, sharing rules, restriction/scoping rules to drive data access for those who need it. Keep security on the forefront of your mind as you move forward and make decisions.
Plan | Okay, we understand the requirements, we're focused on security. Let's start planning. Remember that part where we identified what OOTB functionality can satisfy our requirements? It's not likely you'll have 100% coverage here. That's okay. Let's hone in on those gaps and start to find where vanilla Salesforce doesn't meet our needs. Now, start thinking about how to capture the data (Custom Objects/Fields) and what the best mechanisms are for supporting the processes (Custom Dev/Declarative work). Remember, security should be on your mind still!
Design | Sweet! We made to the design phase! You understand the goal, you've identified how to securely move forward with your plan of attack. Let's do this! One of the primary things to consider at this phase is to design for scale. Most poor design decisions are not immediately noticeable. Typically, a weak data model will be exposed as the application scales due to an increase in:
Volume of data
Amount of processes
Size of user count
Number of integrations
A good data model design makes it easier to continuously refactor your application as requirements are added and extended. And believe me - they will be.
Daily Principle
βMake the best use of what is in your power, and take the rest as it happens.β β Epictetus
When you focus on whatβs within your direct control, you gain power. You improve. You get better.
and now....Your Daily Memes



What did you think about today's newsletter? |