Guide
In Fibery Reports you can use multiple Databases as a source (like on many other Views).
For example, you might want to have on one graph:
Bugs & Stories, grouped by Sprint
Voice conversations & Emails, grouped by month
Features & Insights, grouped by Product area
So, when you create a new Report, you can choose multiple databases as a Source. They can be from different Spaces.
What happens next?
All unique fields from all chosen databases appear on the left
An extra 'field' called Entity Database becomes available, whose values will be the names of the databases
All same-name fields are merged
So, if Bug and Story have "common" aka same-named field-relation - Sprint, Created By, Creation date - it will be shown as a single field on the left.
This chart displays how many stories and bugs are included in each sprint, giving a shared overview of both planned work and reported issues. But I can also create a more granular view in this case - by using the Entity Database field that became available.
Using "Entity database" in report formulas
When you build reports that include multiple record types (for example: Bugs and Stories), the Entity Database field allows you to apply different logic depending on the type of record.
Entity Database contains the name of the database the record comes from — in this case either 'Bug' or 'Story'.
Let’s say you want to count how many Bugs are in your dataset:
COUNTIF([Id],[Entity Database] == 'Bug')
This formula counts every record that comes from the Bug database, and not anything else.
You want to calculate total points, but only for Stories:
SUMIF([Points],[Entity Database] == 'Story')
This formula sums up Points only for records that are Stories. Bugs (and any other record types) are skipped.
Combined logic - separate calculations for Bugs and Stories
Let’s say you want to calculate:
SUM(
IF(
[Entity Database] == 'Story',
[Points],
IF(
[Entity Database] == 'Bug',
[Weight],
0
)
)
)
The formula will:
Note: there are no Lookups possibilities in reports.
Reports cannot automatically pull data from related records. This means that, for example, when you're building a report on the Bug level, you won’t be able to see the Sprint status unless that information exists directly on the Bug entity.
If you need data from a parent or related entity, you first need to create a Lookup field in the source database. This Lookup will copy the relevant information (e.g. Sprint status) to the Bug level, so it becomes available for reporting.