πŸ’ƒ 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!

salesforce developer

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

salesforce developer
salesforce developer
salesforce developer

What did you think about today's newsletter?

Login or Subscribe to participate in polls.