Custom fields are provided based on inventory interval when the inventory interval is set to "Standard" (not Basic) in the Agent Settings. So, for every inventory request, the custom fields are provided. Outside of normal interval times, the inventory is called on machine startup and network change.
By default, the agent will collect a full inventory once, then do a delta of what is changed. If a Full inventory is requested via the admin console, and the above option is checked, custom fields will only be evaluated during this full inventory call.
Inventory data and heartbeat data are different and occur at different times. Why do you want to have the data coincide from a timing perspective?
Some of the Custom Fields that I am inventorying is dynamic and changes quite a bit. I would like the custom inventory to be recent as possible and sync to my SWD Server so that it may be used to deploy software (& scripts packaged as software) based on a computer smart group configured with the custom inventory data.
My standard Inventory Interval is set to 24 Hours for clients in the agent settings and my heartbeat is set hourly. The problem is the 24 hour Inventory interval set on client is not being reached by most clients since most are not on for 24 hours. The 24 hour Interval is not being honored or triggered and is being reset when the computer is turned back. (I think and hope this is fix in your latest version to come out this month). A full inventory request has to be ran from the Admin console keep clients Inventory updated.
I had to disable the Send inventory on startup and network using the globalprefersetting registry keys to prevent user complaints of the frequency and high CPU utilization of the lm.detection (3rd party patching) process that is started during Standard Inventories.
I'm thinking that installation conditions might be a viable workaround for what you're trying to do here. Take the script that you're currently using for the custom field and make it an SD package that writes a trigger file to a temp location on the HD. Create a metapackage with 3 subpackages in this order:
1. Script that writes trigger file.
2. Your package that only installs if that trigger file is present at the temp location (via an installation condition).
3. Cleanup script at the end of the metapackage deletes the trigger file.
This way the custom script is basically only evaluated immediately before the your package attempts to install. You'd have to reset the metapackage and its sub packages are on a regular basis if you wanted to catch devices that don't meet the conditions now but might later. I guess it really depends on what data your custom field is returning.