OData Connector Table Descriptions and Relationships

The relationships and descriptions of tables included in the Power BI Report Sample template, as well as for the primary and related data tables accessed via the OData API are outlined below.

Understanding the tables on this page

The tables in this page describe the (in some cases suggested) relationships between tables available via the OData API for Gimmal Records.

• Table: Name of the table/related table from the OData API.

• Cardinality: The first position of the cardinality corresponds to the table in the far-left column, the second position corresponds to the table in the far-right column.

  • 1 - 1: One row in the table on the left matches one row in the table on the right, e.g. archiverecords to ArchiveRecordsProperties.

  • 1 - Many: One row in the table on the left (can) match multiple rows in the table on the right, e.g. records to recordclasses.

  • Many - 1: Many rows from the table on the left match a single row in the table on the right, e.g. RecordClassClassificationRules to recordclasses.

  • Many - Many: Many rows from the table on the left can match multiple rows in the table on the right, e.g. recordclasslifecycles to LifecyclePhases.

• Cross-Filter Direction:

  • Single: Filtering “flows” from the 1 side of a 1 - Many relationship to the Many side. For example, the relationship between the records (1) and recordclasses (Many) tables - filtering on the records table affects recordclasses, but not vice versa.

  • Both: Filtering can affect both tables in the relationship. For instance, if used with records and recordclasses, filtering the recordclasses table filters the records table, and vice versa. Also referred to as bidirectional cross-filtering.

  • In general, the provided cross-filter direction is a quite strong suggestion for performance benefits and to avoid issues in multiple-path scenarios. While a different cross-filter direction could be used in many cases, that decision is made by the user on a case-by-case basis depending on the actual reporting scenario in question.

• Related Fields: The fields associating data from the table in the far-left column, with data in the table in the far-right column. The first position of the related fields corresponds to the table in the far-left column, the second position corresponds to the table in the far-right column.

• Due to your specific needs, Cardinality, and Cross-filter direction may differ from the information on this page.

• Be careful with creating relationships not included on this page. Even though there may be identically named columns in two different tables, this does not always indicate that there is a direct relationship between the two.

Power BI Report Sample template relationships

General Table Relationships

actionitems

Workflow action items that track lifecycle phase actions for records. Contains approval status, automation flags, retention expiration dates, and links to records, batches, and lifecycle phases.

The actionitems table has the following relationships:

archiverecords

Contains record details and properties after disposition when record classes' “Archive” properties are used.

The archiverecords table has the following relationships:

batchdefinitions

Templates that define how batches should be processed. Contains title, description, priority, and associated classification rules for automated batch processing workflows.

The batchdefinitions table has the following relationships:

batches

Groupings of records (based on batch definitions) for disposition processing.

The batches table has the following relationships:

destructioncertificates

Optionally created when records are disposed.

The destructioncertificates table has the following relationships:

inboxitems

Items that may require disposition approval or other user intervention (e.g. automated action failures or for unsupported actions). Includes all workflow items requiring action, not just those nearing expiration, e.g. internal system actions not viewable by users.

The inboxitems table has the following relationships:

legalcases

Includes the information entered when creating a legal case. Does not include legal holds or legal hold rules.

The legalcases table has the following relationships:

legalholds

Individual legal hold instances applied to specific records/URIs, linked to legal cases. Tracks when holds are created and modified.

The legalholds table has the following relationships:

lifecycles

“Main” table for each unique lifecycle created.

The lifecycles table has the following relationships:

notificationhistory

Audit trail of notifications sent to users, tracking notification type, date, username, and associated batch information for workflow communications.

The notificationhistory table has the following relationships:

recordapprovalaudits

Audit trail of record approvals, tracking who approved what records, when, and whether it was a final approval. Links to batches for workflow context.

The recordapprovalaudits table has the following relationships:

recordclassapprovalgroups

Defines approval groups/levels for record classes, establishing the approval workflow hierarchy, and order for record processing.

The recordclassapprovalgroups table has the following relationships:

recordclasses

Properties of each record class.

The recordclasses table has the following relationships:

recordclasslifecycles

Associated record classes and lifecycles.

The recordclasslifecycles table has the following relationships:

records

Includes the basic properties and property bag for each managed record.

The records table has the following relationships:

retentions

Includes the configuration of each Retention.

The retentions table has the following relationships:

triggers

Includes the configurations of each Event, Date, Rule, and Special trigger.

The triggers table has the following relationships:

Destruction Certificate approvals

Approvals submitted for each destruction certificate.

The Destruction Certificate approvals table has the following relationships:

Destruction Certificate contents

Information included in each destruction certificate.

The Destruction Certificate contents table has the following relationships:

Legal hold rules

Conditions used to automatically apply legal cases to records.

The Legal Hold Rules table has the following relationships:

Lifecycle phases

Lifecycle phase configurations.

The Lifecycle phases table has the following relationships:

Record Class approval groups and users

Defines approval groups/levels for record classes, establishing the approval workflow hierarchy and order for record processing.

The Record Class approval groups and users table has the following relationships:

Record Class classification rules

Classification conditions for each record class, if configured.

The Record Class classification rules table has the following relationships:

Trigger Rules

Rule trigger conditions.

The Trigger Rules table has the following relationships: