Restrict Effort Field Updates in Resource Assignment (SPM Module)

[Ayesha Zia]

We are currently migrating projects from our custom application into the SPM module through a script. Many of our existing projects have some resources whose contract_hours include decimals (e.g., 230.5 hours), and we want to map these values exactly to the Effort field on the Resource Assignment record when the script creates it.

The issue is that, for some records, the Effort value is not retained as entered — it gets rounded or changed, which seems to happen because of some backend Business Rule or configuration.

Here's an example: (please find a video in the attachment for better understanding)

Project X
Resource Y has 1,248.38 hours in the custom module.
- Expected Effort in SPM: 1,248.38
- Actual Effort populated: 1,248


I initially suspected the property com.snc.resource_management.allocation_interval_minutes might be influencing this. Its default is 60. When I tested with different values (6, 12, etc.), the Effort field returned inconsistent numbers, for example:

With value 60: Effort = 1,188
With value 12: Effort = 1,200.4
With value 7: Effort = 1,200.7

It seems like there’s some calculation or rounding logic tied to this property or another rule.

My goal is to allow these exact decimal values to be inserted into the Effort field during migration without impacting the normal behavior of resource allocation or daily allocations.

Could you please advise how we can achieve this, or if there’s a way to temporarily bypass this rounding logic during data migration?

Some other effort hours mismatches I also faced, please find screenshots in the attachments.


Is there a way to temporarily prevent the Effort field from being auto-updated (and allow decimals) during migration, without affecting other functionality?

[Ravi Gaurav]

Hi @Ayesha Zia 

Bypass BRs temporarily (Migration-only run) ( The Same I did in the Past)

• During your migration, temporarily disable the Resource Allocation Business Rules that normalize effort (you can find them by filtering BRs on resource_allocation or resource_plan_task table).

• Run your import script with decimals → Effort will insert as given.

• Re-enable the BRs afterwards.

• Risk: If anything else runs during migration, users might create/update records that bypass validation.

You can programmatically skip BR execution for your migration run:

var gr = new GlideRecord('resource_allocation'); gr.initialize(); gr.setValue('resource', '...'); gr.setValue('task', '...'); gr.setValue('effort', 1248.38); gr.setWorkflow(false); // disables BRs and flows gr.insert();

setWorkflow(false) prevents Business Rules and Flows from firing → so rounding logic is skipped.

• This way you don’t need to globally disable BRs.
  
  

• You could set com.snc.resource_management.allocation_interval_minutes = 1 (or even smaller) before migration.

• That allows more precise decimals to be stored.

• After migration, reset it back to 60 (or whatever business requires).

•  But this might still trigger recalculation depending on OOTB code paths.

[kaushal_snow]

Hi @Ayesha Zia ,

 you can temporarily adjust the system property com.snc.resource_management.allocation_interval_minutes to a smaller value, such as 1 or 6. This property controls the granularity of effort allocations, and setting it to a smaller interval allows for more precise decimal values. However, be aware that this change may impact other resource allocation calculations, so it's advisable to revert the property to its original value (typically 60 minutes) after the migration is complete to maintain standard functionality. Additionally, ensure that any business rules or scripts that might be rounding the Effort field are temporarily disabled or adjusted during the migration process.......

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.