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!?
You no longer have to rely on data feeds that are only used to link content based on matching attributes
Relationships automatically updated as content changes
You can easily build cross-references where related content moves from one cross-reference grid to another (Related Open Findings vs Related Closed Findings)
You can efficiently maintain data relationship integrity in complex data structures. (For example, automatically maintain the relationships of Business Units to Risks based on the ownership of risk by the Business Process held by a Business Unit.)
Once you check the Calculated Field option for the field, the below configuration section is displayed.
The configuration of a calculated cross-reference field has two separate filter configurations. The first section is the Matching Filters section. This section allows you to select fields from the related application compare them to fields in the current application via various dynamic comparison operators. You can compare fields with matching field types with the operator.
Field Value Match
Field Value Does Not Match
Field Value Contains
Field Value Does Not Contain
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!!