Salesforce, the platform which prefers clicks to code. Which is pretty easy to learn (especially with the help of Trailhead) and people/admins/power-users feel (over)confident to make changes on their own, without consulting the original implementator. Or even you – as an implementator – forget some things which can destroy everything you created.
Looking for some examples, which might go wrong super easily?
New Field
There is nothing wrong with creating new fields, you cannot destroy anything as the app didn’t know about it anyway.
Well, unless you mark the field as required in its properties and then all integrations go wrong, as they don’t know they need to fill the field.
Solution? Set it mandatory on page layout, that way users have to enter value when editing the record, but it is ok for everything else.
Validation Rule
Business tells you they have some new validation you need to create and it will be no problem for any integration, as it provides all the values anyway.
The only problem is, that you forgot to check existing records and they don’t respect the rules, so things which runs in background or simple stuff like roll-up fields will stop working. And it is pretty confusing to users, when they want to create a new product on opportunity and get a message that account’s owner is from wrong department.
Solution: check in your validation rules that they fire only when the specific field is changed. And even then check existing records, if they fulfil the criteria.
Duplication Rules
Who wants to see duplicates in their system? No one, easy. The problem here is called Process Builder, because in APEX you can write the code in such a way that it can save the duplicate, just include the following:
Database.DMLOptions dml = new Database.DMLOptions();
dml.DuplicateRuleHeader.allowSave = true;
dml.DuplicateRuleHeader.runAsCurrentUser = true;
List<Database.SaveResult> sr = Database.insert(contactsToInsert, dml);
But then the Process Builder will fire on new contact and all of sudden it isn’t possible to tell it to allow save, even though it is enabled in your duplicate rule. And it will fail, I mean the APEX code will fail because of your process.
Solution: remove the process builder and code it, not aware of anything else.
State and Country Picklist
State and Country picklist is such a great thing, it really helps you to clean the list of countries the users use.
The downside is integration, where you need to pass/transform the values into something accepted by Salesforce. Of course you can change the integration values in Salesforce, but that expect that all systems will provide the same value. If not, your code needs to do the transformation, before you’ll realise this small change you have no idea why it fails all of sudden.
Sandbox folks, use sandbox!
I’m not fan of sandboxes (shame on me!), I don’t believe in them. And frankly, from my experience, your admin/power-user will not be able to test the examples above.
The reason is pretty simple – even if you show them how to run tests, the test will be most likely written in such way, that they will pass.
Hands up developers who write tests with random country name, who fills all fields on records (and even then when they add a new field it is possible to set validation in such way that test will pass but real life not), who have data factory set up in such way that it even don’t generate duplicates (when you don’t know how the client defines them) or rather create them to check that you will survive this thing.
We should’t blame the admins/power-users, remove their rights and force them to sandboxes. We need to explain, show, teach more … and they need to be willing to learn more. Till then, be ready for your code to be broken for unknown reason.
Why it failed?
This article also means that I – after a week – finally know why sometimes the records were created with wrong assignment.
It was quite a journey:
- the integration wasn’t handling duplicates gracefully, duplicate management has been turn on a while ago and no duplicate till that time;
- when the integration was updated (with the code above) the process builder which fired blocked it everything;
- the trigger from vocative app we installed wasn’t ready to be called from batch class (who would expect when writing tests for that trigger, that it might be called by record created from a batch class?);
- the State and Country picklist has been turn-on a while ago and after a few weeks finally there was a record with country specified, just not from the approved list.
Was great week, I learnt and reminded myself of a few things, hopefully you learnt something new as well. Doesn’t matter what is your role. Or didn’t you?