Table of Contents
I have created a whole number field in Account entity called as
Account Age. This value needs to be output when someone clicks a button or changes some value in any other field (triggers could be anything, ultimately you should grasp the concept here), in my case it is on change of Account Name field.
Notice that in this code, I am retrieving the value from
Age field, now naturally we will be required to place this field on the form, right? No, that’s wrong, that’s where injecting dependencies will come in picture. While creating the web resource, there would be a new tab called as
You have the following options available with you
- Add a dependent Web Resource
- Add an entity and the attribute name which are dependent on this script.
- The beauty is that if this script is a common one and a lot of other entities are also using it then you can define all those entities and attributes here.
What happens when this script loads?
Now, I just added the dependency and published all my changes, notice that we have not put this field on Account form yet. It should still give you the result and output the value of Age.
And boom! it just works! Now, lets try to remove this dependency and see what changes.
So there we have it, no more hidden fields on the form.
What are the benefits we get from it?
- No need for putting unnecessary fields on the form just because one script needs it.
- No unexpected script failures as the system will always ensure that the value of this field is available for your script to use.
- System Customizers will be given a warning when they try to delete this field, which happens all the time and results in script failures.