Any way to automate firing of form rules?
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. Exa...
Forum Discussion
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.
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.
I agree with your observations. I look at it as you have to work with the completely unknown ovoid shaped yellow object with a pleasant smell that burns if applied to paper cuts in order to create a pleasing substance that satisfies others.
You can leverage Webhooks to handle some form rule like functionality but you have to know how to write the code, which is easy once you learn how. You can also place controls on fields displayed in Grid Edit by making a separate field that is not "the" lookup field but a formula copy of "the" lookup field. This solution only allows the User to view data and cannot modify "the" field except in the form, I call it abstraction. Duplicates of the same data, shown in different locations. This gets tricky once permissions and Roles come into play. Then Webhooks, separate the permissions and a field you want to hide from input but still want to share the data in the field with the User.
Other options are to disable grid edit and create a path for the User only through forms. If there is a must have use case, separate the data entry/change for that data into a separate table and then do some creative relationship or Qunect with SSMS or PowerBI. Finally you can use something like Workato that on schedule searches a table for a change or boolean and triggers a recipe to do some logic.
Interesting, thing. Workato used to trigger based upon when a formula field updated without User intervention(edit). So if you had a check box formula field that became true 24 hours after Date created, it would trigger a recipe. I used it for about 1 year until more recently that functionality/bug was removed so now it has to be done on a schedule where Workato searches the table for certain boolean markers and then does something.
I see Quickbase as a database/software development environment. Use field properties as software logic, create more than one field based upon some logic and then show/hide different fields depending on which is true and what you want the User to do. Use Webhooks to move data around. Table Rules are also powerful but limited.
Ben's problem sounds like the Solution is a Workato recipe.
Jim
------------------------------
Jim Harrison
------------------------------
You can leverage Webhooks to handle some form rule like functionality but you have to know how to write the code, which is easy once you learn how. You can also place controls on fields displayed in Grid Edit by making a separate field that is not "the" lookup field but a formula copy of "the" lookup field. This solution only allows the User to view data and cannot modify "the" field except in the form, I call it abstraction. Duplicates of the same data, shown in different locations. This gets tricky once permissions and Roles come into play. Then Webhooks, separate the permissions and a field you want to hide from input but still want to share the data in the field with the User.
Other options are to disable grid edit and create a path for the User only through forms. If there is a must have use case, separate the data entry/change for that data into a separate table and then do some creative relationship or Qunect with SSMS or PowerBI. Finally you can use something like Workato that on schedule searches a table for a change or boolean and triggers a recipe to do some logic.
Interesting, thing. Workato used to trigger based upon when a formula field updated without User intervention(edit). So if you had a check box formula field that became true 24 hours after Date created, it would trigger a recipe. I used it for about 1 year until more recently that functionality/bug was removed so now it has to be done on a schedule where Workato searches the table for certain boolean markers and then does something.
I see Quickbase as a database/software development environment. Use field properties as software logic, create more than one field based upon some logic and then show/hide different fields depending on which is true and what you want the User to do. Use Webhooks to move data around. Table Rules are also powerful but limited.
Ben's problem sounds like the Solution is a Workato recipe.
Jim
------------------------------
Jim Harrison
------------------------------
- MarkShnier__You
Qrew Legend
Jim this is a vey old thread, but what the original poster wants can now be handed by a simple native Automation running each night to look for qualifying records and then to change their status. No need for anything fancy.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------- And Quick Base added custom data rules not that long ago:
------------------------------
Adam Keever
------------------------------
