Discussions

Expand all | Collapse all

Any way to automate firing of form rules?

  • 1.  Any way to automate firing of form rules?

    Posted 08-03-2017 16:54
    I know this is probably a no. But is there a way to push form rules to fire automatically without putting the record in edit. I am used to workflows in salesforce which fire in the background. 

    Example would be. I have Accounts and Invoices. I have a field on accounts that shows how many days since last the last invoice. I have a form rule that is setup to change the status of the account to lapsed if the number of days is greater than 20. The change will not happen currently unless you click edit on the account. 

    Any help would be greatly appreciated. 


  • 2.  RE: Any way to automate firing of form rules?

    Posted 08-03-2017 18:13
    I also migrated from SF to QB a few years ago. QB takes a slightly different way of thinking to accomplish the same thing than in SF. To begin with, make sure you understand that the dynamic form rules are great - as long as you are doing all your updates from the form. They really need to be separated out (their validation rules and update actions) into separate objects in the platform, since QB has a huge gaping hole with the fact that you can grid edit or update your database from API calls, and those updates will totally ignore any validations you had set up in your form rules, and also totally ignore those update actions you had set up in the form. The form rules are only good in the form. I view this as the single biggest loophole about QB. Having said that, QB is still leagues ahead of SF when it comes to administrator and developer productivity. There are creative and simple ways around most things, but this form rules one is tough to stomach.

    OK, so to your specific question, what I would do instead of setting it up so that you have to update the status field, either through actual manual editing or through a form rule action, is to have a manual status field, kind of like an override, which would work like the current status field. But the real status field will be a new one that you create that will be a formula text field. For its formula, if someone enters something in the manual override field, use that entry for the actual status in the formula field.  Otherwise, put IF() logic in the formula field to inspect your other fields to determine the status. These rules would be similar to what you would have put in the dynamic form rules, although the formula will look very different syntactically that what a form rule looks like.

    The big difference between SF and QB, in terms of how you architect and implement a lot of business logic, is that QB relies much more on lookup fields and formula fields. You can do more with them than you can in SF.