skip to Main Content

Apply Advanced Logic to Custom Object Assignment with BREeze

Over the years, we have built out several apps designed to help Admins meet the ever-changing (and increasingly more complex) needs of their userbase without needing to pull in developers or deploy extensive code. We often refer to BREeze, our oldest app, as our “swiss army knife” because it’s really an amazing utility tool that provides endless ways you can leverage the App to satisfy your requirements.

Do you have an advanced Lead or Case rule evaluation that can’t be solved with standard assignment rules? Perhaps you have a scenario where you’re doing some assignment of custom object records – this could include just basic ownership, but you might also need to set several field values on the records. Maybe you’ve got a crazy complex scenario with lots of business rules, and you know some portion of the logic will need to be pushed into Apex… however you still want that flexibility down the road for your admins to modify the rule set to meet updated business requirements at any given time. You’re probably thinking, “how are any of those even possibly related?”

In all of these examples, we use the feature set that is available with BREeze to solve the scenario. To better highlight some of these use cases, we’re going to have a series of blog posts walking through how you could utilize BREeze to meet some of your more basic requirements as well as some of your more complex challenges. The topics we’ll touch on over the next couple of weeks are:

  • BREeze Rule Sets for Custom Objects
  • Advanced Case Assignment Using BREeze – Highlighting BREeze Custom Functions
  • Technical Deep Dive

Alright, let’s jump into the first topic.

BREeze Rule Sets for Custom Objects

If you’re familiar with Salesforce’s native Lead and/or Case Assignment rules, you know that as records are created in Salesforce and evaluated against those rules, they are reviewed from the top-down – rule entry 1, rule entry 2, etc., etc. Each entry in your assignment rules has a series of criteria and if the criteria are met, the record is assigned to a specific user or queue. If the record doesn’t meet the criteria of the first rule entry, it moves to the second and this continues until the logic evaluates to true for one of the entries OR makes it to the end without finding a match. Here’s a super simple example of your basic Lead Assignment Rules:
Screenshot of standard Salesforce Lead Assignment Rules configuration
BREeze was built to mirror this type of behavior very closely – but with a ton of added benefits. We’re going to walk you through how you can use this type of logic to build out assignment rules for a Custom Object (but BREeze works with any Standard Object as well!).

First off, you need the free version of BREeze installed in one of your sandbox or developer orgs – I probably don’t need to say this, but we don’t recommend installing directly in production since it’s always the best practice to work in a sandbox or developer org first. Once the installation completes, you’re ready to start building your rules. For this walkthrough, we’re going to be working with a ‘Widget’ custom object however, the same process would apply to any of your custom objects.

To get started on your rule build-out, we’re going to look at the Rule Detail section first. Here is where you’re going to define some high-level information about your rule – the name, the object, whether you’re stopping on the first match, etc.

Screenshot of default Rule Detail Section of a new BREeze rules set
Below, we’ve gone ahead and entered in all of the information needed to frame up the new Widget rule. If you’d like to deep dive into what the purpose of each of these fields is, check out the full BREeze user guide here.

Screenshot of BREeze rule detail customized to work with a "Widget" Custom Object.
We have customized this Rule Detail to work with a custom object named “Widget”

Next up, you’ll start building out the actual Rule Entries – just like you would for Lead or Case assignment rules. The section right below the Rule Detail is where you’ll begin defining your criteria & actions.

As you begin to define your entries, this is where you’ll immediately see the difference between native Salesforce Lead or Case assignment rules. Similar to standard assignment rules, BREeze gives you the ability to evaluate any field on that object against a specific value(s). However, what BREeze also allows you to do is leverage functions – either on the field side of the equation (left) or the value side of the equation (right). We won’t get into the detail in this post around the power of BREeze functions but in short, these are essentially Apex classes that can be called on the fly to make the criteria you are evaluating even more powerful.
Screenshot of a default BREeze Rule Detail
Once you define your criteria on the top half of the screen, you can then define your actions. Again, unlike standard Lead or Case Assignment rules where you can only set an owner value, with BREeze you can also simultaneously set the value on any other field on that object. Or you can use the same power of BREeze Custom Functions that we mentioned previously to set values, create related records, post to Chatter, etc. etc.
Sorry, I’m still not going to cover BREeze Custom Functions in this post and I promise I’ll stop teasing those out starting…now. Back to the Rule Entry definition – once you’ve defined your criteria and actions for that entry, save them and go back to the main BREeze screen.
Screenshot of a customized BREeze rule detail with logic for the Widget process
As you can see from the above, we’ve got a couple of criteria lines defined, one for the Name and another for the State/Province – very similar to what you’d see with standard assignment rules. However, if you look at the Actions column, that’s where things get interesting.

Not only are we setting the Owner for the record to ‘Record Owner D’ but we’re setting a couple of picklist fields, a text field, and then we’re using a pre-packaged function to stamp the record with the name of our rule so we know exactly which BREeze Rule Entry the record evaluated to true for. Pretty cool, right? And this is only for a single rule evaluation. The same capabilities can be extended to every Rule Entry within your rules set. That’s some pretty powerful stuff!

To spare you reading through pages and pages of riveting content on defining criteria and actions, I’ll fast forward through the build-out of the remainder of the rules – tada!

Screenshot of fully built out BREeze rule entry logic for the Widget object
A fully built-out set of rules for the custom Widget object

Last but not least, unlike standard assignment rules which fire only on insert, we actually need to tell Salesforce when your new rule should be executed. You’ve got all sorts of choices on how and when you want BREeze to execute but in short, the most common are either by a Process Builder process or an Apex trigger. With both of those options, you have the choice to run your BREeze rule on insert, update, or on both insert & update – it’s completely up to you. Once all of those pieces are in place for your Custom Object – BREeze Rule Detail, Rule Entries, and a calling mechanism, you’ve got all of the elements you need to conquer those complex business requirements.

If you’re feeling a bit overwhelmed by this, we actually have a package to help jumpstart your experience with using BREeze on Custom Objects. Check it out on the AppExchange!

We hope this gives you a taste for what is possible with BREeze and unleashing its power with your Custom Objects however if you have a question, let us know! Also, feel free to check out any of our other BREeze related resources here.

Thanks for taking the time to check out our post, and stay tuned for our next post where we will dive into advanced Case assignment logic and custom functions!

 

Brian Duvall

Brian is the Product Manager for GearsDesign and is responsible for taking our apps from inception through to launch. He is 9x certified with more than 10 years working with Salesforce, and has a background in integration and data management. When not wearing his many hats working on all things products, you can find Brian cheering on THE Ohio State University football team.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published.

Back To Top