Breeze 4.0 – Smart Processing And Other New Features

January 9, 2017
Brian
0 Comments

It’s hard to believe it’s been nearly four years since we rolled out our first version of BREeze. Early on when we first launched BREeze the vision was mostly around expanding the standard assignment rules, but instead of being restrained to just being able to assign Owners on Leads and Contacts, we wanted to be able to assign any fields on any object in Salesforce. From there though, BREeze quickly evolved into a full-blown rules engine – 100% native to Salesforce – to manage complicated business processes where standard workflow or process builder isn’t enough and to do it with apex code would cause a management nightmare. As we’ve worked with more and more customers with BREeze, it’s been exciting to see all of the different use cases people come up with to use this. Now, as we approach our fourth year, we’re excited to announce BREeze 4.0 and a whole new feature set.

With BREeze 4.0 we decided to take a step back and really work on further supporting the very complex business processes that our customers are approaching us with. Our first challenge was to figure out how to be able to handle even more rules and processing within the standard Salesforce governor limits that we must respect. The second was how do we make it easier to test and debug these very complicated scenarios and determine why a rule may not be firing as expected. Here’s what’s coming in 4.0 to help with these.

Introducing Smart Processing – Smart Processing is the biggest new feature in BREeze 4.0 and without a doubt it’s most powerful. With a lot of the complicated use cases that BREeze is supporting at our clients, BREeze is really just the beginning of the processing. Typically BREeze will create the record and populate fields as needed, but then that insert will fire off other triggers and processing based on the results from BREeze. From a governor limit perspective, Salesforce sees this all as one continual process, so the entire chain of triggers and processing needs to complete in the ten seconds Salesforce provides to finish a transaction. When you’re processing more than one record at a time, this gets even tougher to keep within the governor limit. With Smart Processing we’re able to truly optimize that processing of downstream triggers. Previously, if we were pushing 200 records through a BREeze rule set, we would then send all 200 records off to be further processed without knowing which records were actually modified and need to be processed. Now we’re able to tell exactly which records from those 200 were updated and those downstream triggers can limit the processing to just the ones that are needed and even make decisions based on the modification if needed. This all results in better performance, reduced governor impact and reduce heap space. Smart, optimized, processing.
Debug Log Extensions – The standard debug logs do not work with a standard managed package. Basically, you can’t see what is happening in the debug log when a managed package is updating that record. For these complex business processes BREeze is helping to automate this has been a big issue as we need to be able to see why a record isn’t processing properly. To solve this, we have added four local classes to BREeze that can be implemented by a customer to give them debug data on the following granularity levels: localDebug, localInformation, localTransaction & localPerformance. We have also added a Custom Metadata Type to easily allow you to toggle these on or off as needed. This will give administrators of BREeze powerful capabilities to troubleshoot their processes.
Test this Rule – One of the favorite features for our BREeze administrators has been the ability to test a rule set against a live record in Salesforce – but without actually processing anything against that record. No need to create test data to make sure your rules are running properly – instead you can use a live record that you know should process in a certain way and then test it with your rules and make sure that it does. With 4.0 we have improved upon this by making it even easier to read with new color coding and icons that allow you to see failures and passes much clearer.
Execute Code – One of the most powerful features of BREeze is the ability to executive Custom Functions as an action – essentially giving you the ability to scale BREeze beyond just updating a field and being able to perform any kind of action you need. Previously in the rule we needed to set a field in order to fire this action. Now with 4.0, we can simply execute a class by clicking on an Execute Code button and you’re prompted with the list of your functions to call.
AppExchange Package – With the roll-out of 4.0, for the first time, BREeze will officially be an AppExchange app. We worked closely with Salesforce to make sure BREeze met all of their compliance requirements and we’ll be published as part of this roll-out. For our customers this means additional processing power as AppExchange packages get their own namespace which has its own governor limits. This means the direct BREeze processing will have its own governor limit instead of having to all take into account any pre and post processing occurring.
Lightning Compatibility – With BREeze being a stand-alone application, we haven’t put re-building it on Lightning on the roadmap yet, but we did want to make sure if a user was using Lightning Experience that everything would function for them in BREeze. This involved a few changes, but with 4.0, Lightning users will be able to perform all of the BREeze functionality.
Overall Clean-up – As with any release we also took the opportunity to fix a couple of bugs and clean-up a few things.
- Lookup searches now assume wildcards – Previously with a user lookup you had to type out the entire name. Now it behaves like a standard lookup and allows you to just put in the first few characters and assumes a wildcard search is needed.
- Removed the Rule Description Field – Turns out no one was using this at all and it was taking up a lot of space.
- Workaround for Instances not using Chatter – Previously we had problems installing BREeze into those instances that had Chatter disabled. This is now corrected.
- Test this Rule now validates that any functions being called also have valid classes associated with them.
- Rule Cloning – Cloning of a rules is a popular feature and previously rules would sometimes be inserted before and sometimes after the rule that was cloned. Now it will always appear after.
- Sandbox Licensing – When BREeze is installed in a Sandbox it has no license restrictions and doesn’t need a license key. Unfortunately when a Sandbox was refreshed, the license key was copying from Production and then breaking the Sandbox implementation. Now, Sandboxes still don’t need a license key, but if one is there, it will be ignored.

BREeze 4.0 is scheduled to be live in February and on the AppExchange in March. For our existing customers, we’ll be reaching out with information shortly to schedule the upgrade for you, and if you’re not a customer and want to learn more, please use our Contact Us and someone will get back to you immediately. Now with even more processing power, we have some incredible plans for BREeze 5.0 which we’ll be sharing over the coming months!