Yes, enterprise GRC is evolving faster than ever, driven by generative AI and AI-infused systems. However, every AI journey begins with data and a solid information architecture. Whether you're training AI with curated datasets or crafting prompts using relevant and accurate information, data quality is a critical success factor for any AI-powered GRC solution.

So, ask yourself: Do you have the right data and information architecture in place? Are you using the right technologies to keep your data well-structured and reliable?

One powerful feature OpenPages offers for data management is GRC Calculation. This automation capability allows you to assign values to GRC object fields based on the flexible expressions and operations. Whenever you create, update, or associate objects, GRC Calculations are triggered to automatically update the relevant fields. These updated fields are then used in task-focused views, dashboards, and filters to present the information business users need. They also drive workflows for further automation in review, assessment, and approval cycles. GRC Calculation is highly flexible—it can traverse object hierarchies both upward and downward, and assign field values using a rich expression language tailored to your needs.

Now, enterprise requirements often push the boundaries of technology, right? While GRC Calculation is widely adopted by OpenPages customers, I frequently hear a set of common questions across organizations. In this blog, I’d like to share my perspective on those questions.

Although GRC Calculation has been available for over five years and some of the questions are quite advanced, I’ll explain them in a way that new users can also follow and learn from. Let’s dive in!

1. What determines the calculation to run now, or later?

Say, you assign due date of Action Items based on the parent Issue priority. GRC calculation is good at helping you to manage the due date by the expression. But you may wonder what happens if the stakeholder review results in a change to the Issue priority? Or the Issue priority is assigned by another calculation based on the parent Risk's domain field? Say you reviewed Risks and updated the domain on three Risks, each of which has ten child Issues, and each Issue has ten Action Items?

This is where the calculation queue system helps you. GRC calculation processes the update to ten child Issues and a hundred Action Items in the background, so you don't have to wait for all the descendant objects change at the Risk object domain field change. But wait - you also have another calculation for the Risk Rating. Is it pushed to background as well?

General principle is

• Calculations defined on the object type that you save is processed at the same time as the object creation or the update
• Calculations defined on the related objects are processed in the background, so it would not hold your object save
• Calculations impacted by the object relationship change is processed in the background. Calculations impacted by the copy or move operation is processed in the background, too 

In the above example, the Risk Rating is calculated at your Risk object save, but Issues and Action Items are processed in the background after your Risk object save. The object processed in the background is found on the calculation administrative panel like here:

The "In Queue" column shows the number of objects in the queue, and "Next In Queue" column provides links to a few objects in the queue.

2. Queued calculations are not trending down. Why?

Let's use above example. You now have updated the Risk domain field and save it. You eager to see the updates to the descendant objects and you jump to the calculation administrative page. Normally, the system identifies ten Issues and a hundred Action Items to update by then, and you may find some of them are already processed. But you may find it not trending down as you expected especially when you have more complex calculations and have large data volume. There can be multiple reasons.

2.1. Queue jobs allocation is not sufficient

The OpenPages system allocates background jobs to process the objects in the queue. The default allocation is three jobs, which may not be sufficient if your data volume is fairly large and you have a lot of calculations. You can update the setting /Platform/Calculation/Concurrent Calculation Jobs to update the job allocation dynamically(*1). Keep in mind that if you allocate large number to the calculation jobs, it has impact to the business user application workload. The right balance between the background calculation and the normal business user workload varies by each system's configuration and data volume.

2.2 Multiple chained calculations are defined

You can define calculations that refer a field which is calculated by other object's calculation. This is called chaining of the calculations. In the prior example, Action Item calculation depends on the Issue calculation on the priority field. In the real world example, your calculation may further be chained to Risk object's calculation, Control object's calculation, Process object's calculation.... The way calculation queue system works is

1. identify impacted objects by the object change ( or creation, association etc. )
2. identify impacted objects by the chained calculation
3. repeat chained calculation until all objects are identified
4. process identified object's calculation

As you can imagine, the calculation queue actually grows on the step 1 through 3 above. Step 4 is the moment you start seeing it trending down. Is there anything you can do to process it faster? Yes, in this case, you can evaluate the calculation definitions and see if you can minimize impacted objects. There are a couple of techniques to update calculations

1. Add applicability condition to the calculations so the impacted objects are narrowed down to the subset that really requires updates by the calculation
2. Split calculations to multiple to reduce the object fields evaluated for the impacted objects. The impact evaluation on the step 1 through 3 is based on the definition of the calculation - what is the input field to a calculation and what fields are set by the calculation. Typical anti-pattern is a calculation that sets a lot of fields for multiple use case by single definition. My recommendation is to split it to multiple calculation definitions by the use case, so unrelated fields are not processed by the impact evaluation. If you chain calculations further on related objects, the cost of impact evaluation can grow exponential!

3. I see more objects in the queue than I expect. And it takes long.

Let's go back to the first example of assigning Action Item due date based on the parent Issue object priority. Your Set Field operation looks like this:

if ( [$issue-priority$] == "High" ) then
    [$creation-date$] + 30
else
    [$creation-date$] + 90
endif

Now, the stakeholder review results in the priority change from Low to Medium. Based on the example, the due date of Action Items would not require any change. Would it still trigger the calculation on the Action Items?

The answer is yes. As described on the steps from 2.2, the impacted Action Items are added to the calculation queue and processed in the background. When it comes to the turn for Action Item's calculation, the Set Field operations are evaluated, but system recognizes no change to the object and skips saving the object. This is the case where you find Action Items are in the queue but you do not expect the update to the Action Items.

The complexity actually comes with chained calculations. Say the due date of the action items are used by another calculation, say, on the grand parent Risk object for something like Aggregated Target Remediation Date. This results in the Risk object addition to the calculation queue system because it may require re-calculating the value. The way the queue system works is it identifies all the possibly updated resources and add them to the queue for the recalculation. This results in unexpected queue growth for a simple object fields change.

3.1 Chained calculations in the queue without prior change

Back to above example, the Action Item calculation evaluates all the operations and skips saving the Action Item object since there is no change to the object. Would it still trigger Risk object calculation subsequently to determine Aggregated Target Remediation Date is updated?

The answer is no. The system removes such chained calculation items from the queue as soon as it identifies no change to save the object on the prior calculation. The system is smart enough to skip recalculating Risk objects.

Now you may wonder why the calculation queue system traverses chained calculations upfront and add all the possibly updated object to the queue. As you find from the above example, it may just remove queue items without processing. Why does it add all possible items upfront?

There is a complex use case that requires calculation system to behave in this way. It is called cyclic calculation. An example is:

• Calculation on object A sets field 1 and uses object B's field 2 as input
• Calculation on object B sets field 2 and uses object C's field 3 as input
• Calculation on object C sets field 3 and uses object A's field 1 as input

This can lead to an infinite loop and system may run calculation on these 3 objects forever! To avoid infinite loop, the calculation queue system identifies all the possibly updated objects upfront, and if there is a situation for infinite loop, the object is marked as a calculation error like this:
OP-11613 : Failed to calculate field values of the object xxx because of the circular dependency.

4. Conclusion

GRC Calculation is a powerful functionality of OpenPages to organize your data. There are several techniques discussed above to fit it to your complex use case or ever growing data, such as registry settings, calculation applicability or splitting calculations to multiple.

Thank you for following some of the complex use cases on the calculation!

Appendix

• *1 : when your system is prior to 9.0.0.5 release, it requires application server restart to decrease the /Platform/Calculation/Concurrent Calculation Jobs setting value. Increasing the value is dynamically reflected to the system without application server restart regardless of the system version.

Reference:

• Calculation Fundamentals