If your environment isn't terribly large... maybe run a "Force Data Collection" using the IaaS Extensibility Library workflow. Gauge how long a data collection runs to determine if this is an option for you.
The workflow itself only *triggers* a data collection. There has been concern that a data collection in-flight won't allow a new data collection to trigger, and therefore updates to a machine will not be visible (or other problems will occur--which we haven't seen). We think that it will depend on the quantity of simultaneous machine updates that occur, and where in the collection process the prior data collection is. It has been our experience that no problems have happened, and machine data is updated properly in the IaaS presentation.
The problem with Reconfigure for us was that it isn't very surgical. To give entitlement to Reconfigure allows the requester to do more than we wanted to permit. (e.g. network reconfiguration) We have wished for a long time that the product's built-in Resource Actions would model vCenter capability and precision. Someday...
Alternatively, you can try Rob's workflow (I haven't tried it in VRA 7)
Advanced "force data collection" workflow
Possible to do this from an Event Subscription that runs a workflow on request completion (e.g. CPU Update Request). This workflow could check for the presence of a running instance of Rob's workflow, wait until the course is clear, and then kick off a new instance if a desired timeout wasn't reached.
More Resources
Update CPU count in vRA without Collecting inventory
Refreshing VM CPU/Memory values in GUI as part of ASD action
