Business Rules - Have you used this feature? Share your use cases

[Kurt_Jones]

Have any of you that might be on the Ultimate license term used or experimented with Business Rules (underneath Setup)?  I have found it can be a good tool, like a Swiss Army knife, to use in situations where you might not think of a solution.  I'll share a few instances below that have been useful for our firm and would love to hear how others utilize the function.

1. Users not attaching document to request - users were forgetting to attach docs (think brief) to requests and just submitting, making it difficult to supporting teams to know what was needed.  A business rule was created that looked at that project request queue and to see if the has Documents=false on the request.  False means no docs on the request so when user clicks Submit the request doesn't submit and they get a red banner message telling them to include document for submission...attach a document and the submission goes through.
2. Assure an answer in a section of a form - we have a section on one of our forms to identify client intent on why the request is being submitted.  There are many different drop-down questions (think about a topic like Security and drop-downs that describe factors under for them to choose).  We couldn't make all these questions required with an N/A option in every one as the team felt it wasted time and users were skipping it entirely anyway.  A business rule was created to check if all the questions in that section were blank, if so, it doesn't submit and a message banner asks them to fill out at least one option in that section then submit.  From 0% filling that area out to 100%

Please share any examples you have, I think this is an overlooked feature that has many uses for users...let help everyone out....

[MorganHatcher]

We needed to prevent any edits on a project/task when the project is in a certain status - including custom forms. Simple, but effective. We used the trigger = On object edit for both. 

Example of what we use for Project: 

IF( $$BEFORE_STATE.{status}="CPL" && $$AFTER_STATE.{status}="CPL","Status must be changed from Complete in order to edit.")

And Task: 

IF( $$BEFORE_STATE.{project}.{status}="CPL" && $$AFTER_STATE.{project}.{status}="CPL","Status must be changed from Complete in order to edit.")

[Madalyn_Destafney]

I was just thinking about Business Rules last week, wondering if one could be applied for project creation, that it must have a portfolio and a project owner? Pretty sure they'd have to be two separate rules, but wondering how it would play out for the user, like where would they see error messaging for lack of portfolio and owner?

[KellieGardner]

I used business rules for a client of mine. They have fields that must be updated on the project form before the project can be closed but don't need to be supplied from the start. It happens during the process so business rules seemed like the best option.

There are a few things I discovered while setting it up that users should be aware of. The first two make management of the rules a little difficult IMO

1. Business rules are for the WHOLE system, so you have to build a lot of filters into your expressions to make sure it's identifying your specific project.
2. You can only have one Business Rule "type" per trigger. For example, one edit trigger rule is allowed for issues. However, you can include multiple rules in a formula with nested IF statements.
3. There is a new wildcard option that's available for use in business rules not available in standard text mode expressions. The $$BEFORE_STATE and $$AFTER_STATE wildcards are used in expressions to access the object’s field values before and after any edits.
4. The error message is a little unfriendly for the end user, and I notice that they don't read the whole thing, which drops them before they see my custom message I've built. 

IF({project}.{group}.{ID}="XXXX" &&
    {project}.{categoryID}="XXXX" &&
    {templateTask}.{name}="XXXX" &&
    $$AFTER_STATE.{status}="CPL" &&
  (ISBLANK({project}.{DE:FIELD NAME}) || ISBLANK({project}.{DE:FIELD NAME}) ),
  "Required fields need to be updated",
IF({project}.{group}.{ID}="XXXX" &&
  {project}.{categoryID}="XXXX" &&
  {templateTask}.{name}="XXXX" &&
  $$AFTER_STATE.{status}="CPL" &&
  (ISBLANK({project}.{DE:FIELD NAME}) || ISBLANK({project}.{DE:FIELD NAME})|| ISBLANK({project}.{DE:FIELD NAME})),"Required fields need to be updated"
))

[KellieGardner]

[KIMBERLYREA]

We are in the process of testing a Business Rule for project names not to include special characters.  This will help us when we create our SharePoint folders from the project name not to have an error message.  

We also have one set up for a team that is for now allowing a request to be entered without documents attached to it.