
Let’s keep this 6.4 feature train going with an overview of the new Calculated Cross-reference feature. This feature will allow for the dynamic and automatic building of relationships between content based on the contents inherent attributes. Calculated cross-references are just like standard cross-references other than instead of manually establishing the relationships or building data feeds to manage the relationships, the Archer system builds and maintains the relationships for you based on a filtering configuration provided by the admin. The configuration allows for field comparison criteria allowing the relationships to be built on matching attributes between two applications. It also allows for further refinement of the relationship based on field attributes of the related application.
What does this mean!?
The field types that can be compared include.
The calculation configuration requires at least one matching filter. Advanced operator logic can be provided for that section.
The configuration also has an Additional Related Filters section. These filters are only against fields in the related application and thus support any operator supported in Advanced Search. These filters allow you to further refine the records collected via the matching filters. For example, I only want to collect Findings with a Status of Open. You are not required to provide Additional Filters. This section can also have its own Advanced Operator Logic definition. When the calculation is executed the additional filters are essentially AND’ed with the matching filters.
Let’s take an example. Consider that as you test controls based on results you may open Findings against those controls. Consider that you also want to give visibility to any of these Findings at the Business Unit level based on Business Unit ownership of the Finding. Say you also want to highlight Findings that are still Open for the Business Unit but also maintain a link to all Closed Findings for that Business Unit. Before the Calculated Cross-reference you would have had to create multiple n-tier reports and multiple data feeds to gather the controls and their finding, link them to the proper Business Unit. Depending on how current you want the link between Business Units and Findings to be, you would have to run these feeds on a relatively high frequency to update the relationships based on changes in Findings. With the calculated cross-reference you can remove all this overhead. Let’s look at how you build this.
Our first criteria is that for any Business Unit we only want to link to Findings that are associated with Control Procedures that are owned by the Business Unit. So the answer to the question what attribute do the Finding and the Business Unit have a common?...the Control Procedures. This means we need to configure a matching filter that compares the Control Procedures Cross-reference of Business Unit to the Control Procedures cross-reference of Findings. We will use the Field Value Contains operator assuming that both a Finding and Business Unit could have multiple relationships to Control Procedures.
Our second criteria is to show only Open findings in this cross-reference. Consequently, we will add an Additional Filter for the Findings Status.
Now as we relate new Controls to a Business Unit, this cross-reference will also automatically link to any Open Finding tied to those Controls to the Business Unit.
Since we also want to maintain the relationships to Closed Findings for historical purposes we will create a second calculated cross-reference. This cross-reference will have the same matching filter criteria but the Additional Filter against Finding Status will collect only those that are Closed. This will allow you to have two cross-reference fields that are automatically updated as the status changes.
One interesting item to note for calculated cross-reference is that the associated related record field is also calculated using this same configuration. This means when a field used in a matching or additional filter is updated, the relationship is calculated in-line on the related record side as well. In other words the calculated relationship between the two applications is updated immediately, no matter where the save occurs. This removes the need to queue recalculation jobs to support the maintenance of these dynamic relationships.
I am excited to see how this powerful feature is leveraged in building solutions!! Please join me for this week’s Free Friday Tech Huddle to see this feature and others detailed in blogs to follow!!