If you’re a newly qualified admin, congratulations! Your path to a successful and impactful career in Salesforce starts here. This may be your first job in IT, or the first time you’re getting hands on with the system.
To help you on your journey, here are five industry-standard IT concepts to learn and understand as you blaze your trail. Let’s get started.
1. Keep it Simple
You’ve been given the keys to your Salesforce org and the power to do many things. But, with great power comes great responsibility, so ‘Keep It Simple Stupid’ (or KISS for short) – the US Navy have been using this acronym since 1960!
Less is more when designing record pages. Think about the minimum number of fields needed to fulfill a process and move everything else to another tab, or use dynamic forms for custom objects. Overwhelming users with too many fields can prevent adoption of the system. Consider using page layouts and record types to create bespoke layouts for different sets of users or business processes.
Make navigating through a process super clear – label your buttons concisely and clearly, and be sure to place them in consistent locations. For example, perhaps “Edit” is the first button on every record page. Treat every user like it’s their first day working for your company and the first time they’re using Salesforce. They should intuitively know what to do next.
Ask yourself ‘Why?’ three times to be sure you can’t use a standard object, before creating a custom one – don’t over-engineer a bespoke solution when native functionality can achieve the same thing. You have record types, page layouts, and Lightning Pages to structure your standard object usage. The best features from Salesforce will be available on standard objects first.
2. Separation of Concern
Modular systems are the easiest to manage, upgrade, and maintain. Separation of Concern is a software design principle that encourages designers to section individual functions in autonomous units. These units may be changed independently without a cascade effect on other units.
Here are three important steps to keep in mind:
Avoid complex processes
Avoid creating large and complex processes (like flows) that are difficult to troubleshoot or change; instead, separate your flow into a connected set of subflows – this pattern is sometimes referred to as componentization. Check out these best practices when creating flows.
Good housekeeping
Put yourself in the shoes of the admin that follows in your footsteps and ask yourself the following questions: How easy would it be to troubleshoot an error within your process? Have you designed it so it can be easily pinpointed and fixed, or is it buried within unconnected processes?
- Prepare for the worst case scenario – in case something you’ve built is causing a production issue – by adding a ‘Kill Switch’. By creating small, modular features (for example, through a subflow), you can isolate the problem without having to turn off connected functionality.
- Label your components using the business capability they support. For example, create components prefixed with “SalesProcess…”. If somebody then reports “I have an issue with my Sales Process”, you can easily trace the logic firing.
- Descriptive naming across the board – that’s everywhere… your component names, flow variables, actions, and fields. Instead of “SendEmail”, use “SendEmail_SalesProcessOppClosedWon”. This helps visually understand your logic, and will be a great timesaver if you need to debug a problem using log files.
User permissions
Think Permission Sets not Profiles: multiple permission sets over one monolithic profile is a great way of separating user permissions, and makes it easier to create granular access.
3. Error Handling
Salesforce handles most errors, but in some cases you get system generated errors (see below) that aren’t all that useful for your users.
Whilst you’ll do everything you can to avoid your process failing at all, plan for errors to be handled gracefully. There should be a clear path for the user to take, with any error explaining in human, readable language where the problem lies. The above example is not a ‘graceful’ error because you can’t tell what failed, what succeeded, or what you should do next.
Whilst you can’t control all error messages, there are multiple areas where you have a lot of influence. Here are three:
Be precise when entering error messages in places like Validation Rules. Validation Rules, and the subsequent error messages they provide, exist to ensure quality data is entered into Salesforce. Which of the following messages do you think will provide enough information so that users understand what is required of them?
When you create or update a record, that’s where you’re most likely to hit an error you need to handle. Build in fault paths to your flows after every record action. Be descriptive in displaying to the user what failed and what worked so they know what to try next.
Log errors in a consistent way so there is one location to understand issues, for example the Case object. A fault path in a flow could create a Case record that describes the exact step, user, and date/time of the error, keeping you one step ahead of your users before they log a ticket.
4. Testing
Testing is a specialism in its own right; some organizations set up dedicated test teams or robotic processes to run tests regularly. If you don’t have a dedicated testing team supporting you, follow these four principles to test your work:
- Test little and often (often referred to as Unit Testing). Test small components of your work (for example, a single subflow) before moving on to the next build item. This provides early feedback, and avoids wasting time building a complex process that was flawed due to a mistake made earlier on.
- You’ll be keen to test if your process operates as expected when receiving all required inputs from the user. But what if the user strays halfway through the process, or enters something they shouldn’t? This is called Negative Testing, and ensures you have a robust process regardless of how the user behaves.
- Even if your new process works fine, you may inadvertently affect other functionality through your changes. Regression Testing is running a set of fundamental tests that validate the core application works after a change. Maintaining a regression test script is important for system stability.
- When performing tests as you build, you’ll likely be (unit) testing one record at a time. In production, users may perform this on multiple records at once, such as via a mass edit in a list view. You’ll need your process bulkified so that you can test how your change performs when run in bulk.
5. Document by Default
It’s your responsibility as a good citizen of the platform to clearly and concisely document the system as it evolves. Always put yourself in the shoes of the next admin who inherits your org – how easily would they be able to make a change or troubleshoot? What can you do today to make it as logical and straightforward as possible for your successor to understand the way your Salesforce instance has been configured?
- Make the ‘what’ skimmable: Give the reader the ability to skip sections that aren’t relevant, and use indexed headers to allow them to navigate. If a critical process stops working in production, the last thing you need are paragraphs of unstructured text to wade through when looking for an answer.
- Don’t leave out the ‘why’: There are a number of ways to achieve a goal in Salesforce. Describing why you took a certain route helps others understand your choices better, plus they could potentially follow your patterns to extend an existing feature.
- Use Salesforce description fields to ‘self document’: A field or flow without sufficient descriptions should never reach production! Give some good context, and provide traceability back to a feature or requirement for future reference.
Summary
Some of these concepts may seem challenging at first, but if you build these into your everyday working patterns, they’ll soon become second nature. Using these industry-standard concepts will increase the quality of your work, and keep you aligned with other IT professionals in your organization.
Plus, it never hurts to be curious; see how peers managing other applications are handling general IT concepts (such as testing or error handling) – there may be standards you can reuse without having to create them from scratch.