I was presenting at Tahoe Dreamin’ 2018 with Meighan Brodkey (@meighanSF) on Jan 19th, 2018. We had so many questions raised in the Q&A, so many people who posted us later on, so that I think it’s worth to not just share the slides, but elaborate on that in a series of blog posts. If you need a quick overview, the slides are already up on slideshare. This is #1 in a series of five blog posts, covering the high level principles that we were advising you to adopt for your declarative development lifecycle.
Our session announcement was as follows:
IT SIMPLY WORKS! … UNTIL IT BREAKS
STANDARDS, BEST PRACTICE AND ENTERPRISE PATTERNS FOR DECLARATIVE SOFTWARE DEVELOPMENT
Salesforce empowers non-programmers to become App Builders and declarative developers in ways that administrators could only dream of before Visual Workflow and Process Builder had been introduced. With great powers comes great responsibility, and just because you actually could click a sweet process straight in production doesn’t mean that you should do so. Meighan and Daniel are going to present patterns for building your apps not just faster, but also better, more sustainable, and more robust.
Turns out that a good number of people found this session to be worth attending.
To put in ine sentence: If you want to build awesome point & click applications that are robust all the same, you need to think and work in patterns and ways that most Salesforce developers know and follow by heart. Or they know that they should know.
Just take a step back and reflect on your patterns? Do you do changes in a way that is compliant to a standard workflows? Which permissions do you grant yourself in your production org? Or even in your client‘s production org?
There are some patterns Salesforce developers have, though, that you shouldn‘t follow.
- This is not really documentation:
/* * 2012 by Daniel
* TODO: docs
*/
And seriously, this isn’t inline documentation neither
// magic happen here
-
- This is not really building for scale:
for (Account a : accs) {
update a;
}
-
- This is not really a unit test
@isTest ... i++;
i++;
For sure, you can be sloppy with all of these when you’re developing things in a sandbox. And we’re not gonna point fingers at those who did push such things to production. We all did (and do) this in emergencies or when in hurry. But we have to do better and clean up as soon as possible.
Now that we showed what’s not good – let’s look at the way we’re going to do better in the future.
Some words on enterprise development patterns
What do we mean by enterprise patterns?
Enterprise application are required to work at all conditions, at all scales, robust, stable, predictable, proven, auditable, built and tested to implement best practice and standards rather than bleeding edge technology.
What we mean by enterprise patterns are processes and habits that reduce random or unpredictable results, and therefore mitigate and reduce risk for the org’s health and data integrity.
Using Enterprise patterns also means: Establish a workflow, make steps compliant and follow best practice in terms of quality, engineering and security standards. Then adhere to it and track that you’re following this process. Take the standards that you expect from enterprise grade software development and use them in your declarative customisations.
The well known ISO 9001 is known as the “Quality Management” norm. Yet, it doesn’t give a normative definition of what quality means. But it requires companies to define what quality means to them, and which steps they want to define for their quality management process. A compliant process should then be followed and reflected.
Change Management
The most important pattern is establishing a routine for handling changes, starting from the requirement, etching out a solution, breaking it down to user stories and tasks, and eventually documentation on changes and deployment.
It all begins with the way you collect change requests: Let users give you some explanation – commonly referred to as a “user story” (As <role> I need <feature> so that <task/problem to solve>. This “story” can initially be rather large. We call it an “epic” if it is to unspecific and can’t be completed in a given timeframe. A natural, non-technical description is key to a successful implementation.
The second most important step is not to start straightaway: It is crucial to consider HOW you’re going to do changes. While Salesforce gives you the ability to change almost everything straight in production, this doesn’t mean you should work that way. If you look a little closer, Salesforce even warns you to make any changes directly in production.
You might have heard this already, but a core principle to reduce or avoid an unpredictable state of your org and logic, and therefore a number one advice if you decided to treat declarative changes in the same way you treat enterprise software development:
- Don’t develop in your production org (except reports, dashboards and list views),
- don’t have even have more than a few people with the permission to bring in changes.
- Establish a role for this job, take care to select experienced people for this role and make sure they understand that they are the keepers of your org.
- Establish a consistent workflow to migrate your metadata
- Establish a consistent way to model data for your project
A consistent Change Management is about two crucial things: A process to collect WHAT to do. And a process that defines WHO can do these things, in WHICH environments, and HOW these changes are going to be transported to production.
Documentation
Knowledge about an existing org is often stored in someone’s notes – or even his/her head – exclusively. And both are essentially bad places to put crucial information in. Whatever you’re about to do with your org – make sure that all information about customizations is shared in some accessible ways in a comprehensible form.
It’s not about being perfect right from the beginning. If you didn’t document right from the beginning, you will have a hard time to “retro-document” everything. Yet it is overly important that you keep your knowledge about the org somewhere accessible.
Have you ever “inherited” an org? <Ask the audience> Did you find at least some documentation?
In an ideal world, you will create an index of all object and all logic, that explains – most important – the ideas and rationale – THE WHY – behind customizations.
The world is not ideal – we know that. Make a humble start: Try to write down – at least for your new customization – why you did it and what you did. Whenever you touch something, make it a habit to write this kind of documentation for something that’s already there. You will see that very soon, a nice compendium to refer to will be around.
Little Helpers
- Elements Cloud (freemium)
- Config Workbook (app exchange, free trial)
- Wiki & Issue Trackers (e.g. Jira/Confluence)
Consistency
Another important factor is the way your org looks like – from the front end to the APIs – there should be one common theme across all places. We call that consistency and whatever changes you do, make it fit in with existing customisation and configuration.
This goes in particular for the API names – even though Salesforce auto-populates the fields, you should invest 5 seconds to create a meaningful name that fits in with the existing field names (and with the Salesforce logic of fields).
The same is true about data model and architecture. Salesforce’s standard objects give you a lot of examples how to model data. You should copy these patterns (in naming and design) and not try to reinvent the wheel . Salesforce objects appear to have less normalization than you might expect and follow a domain driven model. Nothing will ever improve if you aim for 3NF for your data model. Instead, try to understand Salesforce’s security model, and the metadata types, so that you know field types, objects, custom settings, and custom metadata types and their relations and use cases by heart.
Consistency is even more important in the front end. Never let Salesforce put new fields automatically on the layout. Always place them manually, and always aim high: You’re building the FACE of your application, so your users should have a smooth experience when working in the UI. Everyone — users, admins, coders — they all rely on you to build consistent patterns that they can adapt to.
Simplicity
Talking about enterprise application that are often designed to solve massively complex problem, it might sound way to easy a solution (maybe even ridiculous): But the old Salesforce rule always applies: Choose the most simple tool to solve a problem, and avoid mixing tools. If you can’t avoid more than one automation tool, mix Apex with Workflow Rules (old neighbours that are really close friends nowadays) or Process Builder with Flows (they’re twins, anyway). If you have to mix Apex with Process Builder, choose Process Builder with invocable methods.
Performance is another consideration: If you want to compare performance, you can monitor the flow of your solution in the developer workbench. Remember that it is in the nature of statistics that 20 or less measures don’t tell anything. So run at least 20 measures per solution (preferably 100) until you judge performance.
Remember that in the lifecycle of every application, there’s a time when no skilled person is around any longer, but the client needs to change condition A to now check for C instead of B. Plan ahead and build your solution accessible
- in a way that people can look at configuration and setup and understand what your logic is supposed to do
- in a way that an admin can modify or extend your logic to adapt to changing conditions
- in a way that all configuration or logic flow conditions are kept in one place, with meaningful labels, so that an admin can re-configure
Wherever possible, avoid monoliths. The fact that you are trying to solve a single requirement doesn’t mean it has to be solved in a single component. Salesforce has introduced delegation for most of its declarative tools: Use it and create one controlling process and several processes to be invoked by the main process.
Scalability
Building for scale is typically the hardest thing to learn on the Salesforce platform. Programmers have to learn a pattern called “bulkification” to escape the notorious “limits”. And as a declarative builder, you will have to, too. Except that there’s no bulkification pattern to follow. It’s only awareness, planning and testing that can save you from disaster.
Therefore, keep in mind: Any logic has to work if you change one record, but also for millions of records or thousands of users at the same time. Even though you often test by single records, everything needs to work as well when a data import pushes thousands of records in chunks of 200.
Any solution that you build can break
- for any number of concurrent records ranging from 1 to 200
- or not all
So: Always make sure to test with 200 records at the same time. It’s the one magic number.
Test-Driven
From the understanding that business requirement are a problem that you’re trying to solve, you should consider to model test cases that match your acceptance criteria or business requirements (in most cases, your tests have to be written down as a test plan, but in some lesser complex cases, you can even build your test in Process Builder).
You can then model your solutions to solve test cases.
Remember that tests should always stress every aspect of your solution. It’s a great idea to try and break your solution to learn about the weaknesses and things you didn’t consider.
If you broke down your solution into smaller parts, try and make them testable and keep notes on how to test them, including the expected outcomes.
Testing for declarative development isn’t easy at all. Start with small ambitions and try to get better and more ambitious with every run.
To monitor the health of “the rest” (i.e. Apex), metadata tools like Copado or Gearset offer test execution schedules and change monitoring (partly even in free plans). And for (in parts) declarative testing, tools like Selenium (there are indicators that it’s slowly dying), Provar, QF Testing and many more to build and run tests from a point & click UI.
I will follow up with upcoming posts for all four stages of the development lifecycle: Design (Plan) – Build (Develop) – Test – Deploy, so please check back from time to time or follow me on twitter @stangomat.