You know that one special gift you get for your kids birthday that you can’t wait for them to open. You just can’t wait to see the smile on the kids face when they get their hands on it. That’s how I feel about this next 6.4 feature – the Report Object. The Report Object gives you another great tool to dynamically and effectively leverage data relationships within Archer. The Report Object provides capability to embed reports onto the View/Edit page from any application and filter the results such that it has context with the current record. Because reports can include n-tiers of a hierarchy, these report can provide a “single pane of glass” based on the current record. For example, by embedding multiple reports on the record page for a Business Unit, you could achieve one entry point to view the full risk posture of a specific business unit, including identified risks, control environment, actual loss events etc.
Let’s look at the configuration for a report object. The Report Object are simply layout objects that you add via the layout of an application. Similar to other layout objects you can control both the column and row span on the layout.
The name of the report object will be used to label the report on the layout at display time. The configuration has a report selector which allows for the selection of one report from any application/questionnaire. By default, the filter section will display any filters defined for the base report selected. These base filters can be completely overridden. It is important to note that if the base report is n-tier, the report object allows for the definition of filters of any application included in the base report. Similar to the Calculated Cross-Reference the Report Object configuration allows you to dynamically compare fields between the current application and any application included in the report. This is what really opens up the utility of the Report Object.
The configuration allows you to compare the following field types.
- Text
- Numeric
- Date
- Values List
- Cross-reference
- Related Record
- User/Groups
- Record Permission
- IP Address
Depending on the field type the following field comparison operators are available.
- Field Value Match (all field types)
- Field Value Does Not Match (all field types)
- Field Value Contains (all field types except Text, Date, and IP Address)
- Field Value Does Not Contain (all field types except Text, Date, and IP Address)
- Field Value Greater Than (Date, Numeric)
- Field Value Less Than (Date, Numeric)
- Field Value Between (Date, Numeric)
- Field Value Contains Inclusive (Hierarchical Values List)
- Field Value Does Not Contain Inclusive (Hierarchical Values List)
- Filed Value Contains Current Record (Cross-reference, Related Record, Filter By Record)
- Field Value Does Not Contain Current Record (Cross-reference, Related Record, Filter By Record)
Now let’s see this in action. It desirable from a business unit record to create a picture of the risk profile for that business unit. Let’s assume that this particular corporation associates risk to business process they affect. Let’s also assume that a business unit is solely responsible for 1 to n business process. You would like to provide each business unit manager with visibility into the risk profile of the processes they own. Prior to the report object, there was no easy way to show details about risks for each business unit, since the risks are really associated to the child business processes. Similarly we wish to show details about the specific Loss Events their child processes encountered.
Here is an example of several report objects shown on the U.S. Finance Business Unit record. The important thing to understand is that there is no direct connection between the Risks or Loss Events aggregated in the reports. They are not held in a cross-reference in the Business Unit record. Instead this data is based on a hierarchical relationship between Risks or Losses to Business Processes to Business Unit.
These are all configured using base reports that includes a relationship to Business Process. For example, take the Risk Scorecard Report Object.
Here is the base report….Notice the report is based in Risk Register and we have added a relationship to Business Process. This was so we can leverage the buildout of risks to business process.
Note adding the buildout to Business Process allows you to filter on Business Process fields in the report object. Then in the report object, you add a filter for the Business Unit related record field in Business Process. Since Business Unit is the same application/level of the report object I can select the Field Value Equals Current Record operator. This ensures that the base Residual Risk Scorecard report will only include risks tied to Business Process where the current business unit record is selected from the Business Unit related record field.
The user can click Display Report from any Report Object on the View/Edit page to pop this report out into the Standard Search results page.
The displayed report will inherit all the dynamic filters that were applied for that specific record. Since it is the standard search results page, the user can execute all actions available in search results: In-line Edit, Bulk Actions, Drill-in, Chart Manipulation, Save Report, Modify etc.
Looking forward to everyone opening up the power of this new feature. Hope you can join me for this week’s Free Friday Tech Huddle to see the Report Object in action!
6 Comments
