Great question. You're not modifying the business rules themselves by adding the dictionary attributes. You're modifying the table (e.g. sys_script) that drives the business rules. That table/fields has not been modified in a very long time so risk of upgrades is negligible. Not zero, but not too concerning IMHO. You would be wise to document changes like that in any case.
That's because UI Actions use the "Condition string" field (that takes JavaScript) for conditions, not the "Condition" field that is represented as the condition builder and stores encoded queries. I know, not the best naming of field types. This video applies to the latter only.
This is magical. Waiting for more DYK videos.
Thanks. More coming. I created two more yesterday.
Love these short tips and tricks. It makes life so much better:)
This is awesome!! Love these DYKs!!
Thank you
Great information for users to know! Thanks!
Great vid. Wish the platform would have these settings on by default!
Simply amazing ❤
Thank you
Thanks for the great tip Chuck
I wonder if the records be skipped if we happen to the change these attributes on OOTB fields like on BR's. Emails?
Great question. You're not modifying the business rules themselves by adding the dictionary attributes. You're modifying the table (e.g. sys_script) that drives the business rules. That table/fields has not been modified in a very long time so risk of upgrades is negligible. Not zero, but not too concerning IMHO. You would be wise to document changes like that in any case.
Didn't work on UI actoin conditions
That's because UI Actions use the "Condition string" field (that takes JavaScript) for conditions, not the "Condition" field that is represented as the condition builder and stores encoded queries. I know, not the best naming of field types. This video applies to the latter only.
@@ChuckTomasi thanks for letting me know 👍
just found this- bummer on 'condition string'- needs a similar solution- condition_builder=v2 would be great