Today’s post continues my blog series from last week, taking an in-depth look at two critical issues that occur after launching a product on the AppExchange:
- failure to play well with others
- failure to play well with customers
The Situation
Last year, a client reported a strained relationship with one of their customers due to an issue with the application we built. Essentially, as far as the customer and our client could discern, the application wasn’t working. The complication? It worked fine in our development org, in our QA org, and in other customers’ orgs. It just wasn’t working in this customer’s org.
Under the Hood
To start the investigation, I opened the debug logs in the customer’s org and began running the batches for the application. The application required two batches to execute: performing API calls to the client’s database to retrieve data, which was then inserted into a variety of custom fields within the list of standard and custom object records. At first, the batches ended in “success.” Of course, looking over the application, I could tell that the Apex Job was clearly lying to me since there was no data populated within the records. It turns out, there was a brief delay on the Salesforce side, and upon returning to my debug logs, I was promptly greeted with CPU limit issues.
Then, I discovered that our batch was initiating a cascading event of trigger updates within the Accounts object in this customer’s org. The customer had dozens of triggers for their Account object, both from managed packages they installed and custom triggers they wrote. The issue was quite apparent. Fixing it, however, was not easy.
The breakdown? We should’ve kept our sights less on building the application to work in our environments, and instead to work in the very busy, and highly customized environments of real world customers. I know you’re thinking, “that seems impossible.” And for the most part, you’re right: it is impossible. So get used to getting bug tickets and learn from them. Hell, cherish it!
What To Do When Faced With Chaos
The issue wasn’t bad code. The issue was that our application, along with every other managed package in that org, wasn’t designed to cooperate with other managed packages. We, like greedy little pigs, were hogging up resources with our operations, without any sense that other operations could be competing for those same resources.
How do you build an application to work well with other applications, when you have no idea what an org will have in it?
To start, consider changing your focus less on passing security review and clearing your quarantined QA process. Instead, think about the chaos you are about to step into. Here are some suggestions I find very helpful:
- Customizable Batch Process
Unless you absolutely have to have a batch run at a certain time and size, leave those decisions up to the System Admin. This allows you to put the decision-making burden on the person best equipped to make it. System Admins have to manage a wide-variety of operations within their orgs. Being able to schedule batches and the size of these batches, according to their org’s setup, is a huge asset.For our client, we introduced a means where we could “adjust” the batch sizes on a per org basis. Now, the batches are running and updating without hitting any governor limits due to cascading update triggers from other applications.
Hard lesson? This was completely avoidable, and placed a well-established relationship between our client and their customer on the rocks. Ask your sales team how often they’d like to be placed in that situation as a guide to how important it’s to consider customizing your batch operations before you release your product to market.
- Leveraging Process Builder and Flows
I almost always grit my teeth when Process Builder and Flows are mentioned for a managed application. Don’t get me wrong, they’re fantastic products. However, invariably I become the crusher-of-dreams when I have to rain on someone’s parade. Here’s why:– When considering these options, ask yourself, “do we want the user to be able to ‘turn off’ this process/flow?” If the answer is no – especially if it breaks any other internal process to your application – then don’t use it.
– Now, if this process or flow is something that isn’t material to any internal operations to your application, then absolutely leverage it. The reason being is the same as I mentioned above. You want to give as much command over your application’s operations to the System Admin as possible. Remember, they need to integrate your product to their org. It’s about them, not about you.
- Customizable Trigger Operations
The first thing you should consider when dealing with triggers is whether you’e planning on putting that trigger on a standard object with a lot of traffic, like Accounts, Contacts, Leads, or Opportunity. If you can avoid it by finding another route, TAKE IT. If not, consider leveraging a batch task that does the same thing. Definitely introduce an Apex class to control for recursion.When approaching a trigger, if the operation it’s performing isn’t required for some critical internal operation but you can’t leverage Process Builder, then provide the System Admin with the ability to opt out of it.
For our client, there were so many triggers in that customer’s Account object that other applications were also failing to properly execute, not just ours. In our case, we tried every solution we could consider but still had no other option than an update trigger on Accounts. We were able to control the cascading events with a batch change.
You may be looking at my suggestions as too obvious. You’d be amazed at how many applications out there don’t abide by these simple suggestions. I know, because I built some of them. I’ve had clients who didn’t want to invest the money on these items and waited to address them after Security Review. The result? Those applications had problems playing well with other applications.
Remember Your System Admin
When building your application, you’re going to come across items besides the ones I mentioned that will guide your decision-making process. My list isn’t all-inclusive, but represents the common items from my experience. If you walk away with anything from this blog, it’s to start considering the System Admin that will be installing and setting up your application, and how they are going to do it in relation to all the other operations and applications they have in play within their org. This doesn’t mean you need to think less about your end-user personas. Rather, you need to add a new persona to your users list: the System Admin.
Check out the next installment of this series here.
