Guide
When creating a Report based on Fibery data, as well as choosing the database(s), it is possible to choose between Current and Historical data. This guide will help explain how these two report types differ.
Entity modifications
Any entity may have undergone lots of modifications in the time since it was created until now. For example, imagine a Task that has the following history:
Created on 15th January 2020, with Effort = 10, State = Open and no Assignees
On 3rd February 2020, the State was changed to In Progress
On 20th February 2020, Steve was assigned
On 21st February 2020, Mary was assigned
On 3rd March 2020, the Effort was changed to 20
On 10th March 2020, the State was changed to Done, and all Assignees were removed
This entity can therefore be represented therefore as a series of modification events:
| Effort | State | Assignees |
15/01/2020 | 10 | Open | |
03/02/2020 | 10 | In Progress | |
20/02/2020 | 10 | In Progress | Steve |
21/02/2020 | 10 | In Progress | Steve, Mary |
03/03/2020 | 20 | In Progress | Steve, Mary |
10/03/2020 | 20 | Done | |
Current data Reports
As the name suggests, a Report view that uses Current data will be based upon the entities in the database(s) as they currently are. That is, their field values after the latest modification event. In the example above, this means only the last row in the table.
If an entity is updated, a new modification event is created and the Report will be revised to reflect the changes (on the next update).
Historical data Reports
In contrast, a Report view that uses Historical data will have data points representing every modification event.
Additionally, each modification event has extra parameters that can be leveraged in Reports. These include:
Modification ID - a unique identifier (positive integer, except it is always -1 for a creation event)
Modification Date - the date and time of the modification
Modification Valid To - the date and time of the next modification
Modified By - the user responsible for the change
Changed Fields - the fields that were changed
Furthermore a couple of useful calculated parameters are available:
Duration (Days) & Duration (Hours) - the difference between Modification Date and Modification Valid To in days or hours.
The modification events for the Task described above can now be represented as follows:
Modification ID | Modification Date* | Effort | State | Assignees | Modification Valid To* | Modified by | Changed Fields |
-1 | 15/01/2020 | 10 | Open | | 03/02/2020 | Chris | |
23 | 03/02/2020 | 10 | In Progress | | 20/02/2020 | Alex | State |
27 | 20/02/2020 | 10 | In Progress | Steve | 21/02/2020 | Alex | Assignees |
30 | 21/02/2020 | 10 | In Progress | Steve, Mary | 03/03/2020 | Mary | Assignees |
51 | 03/03/2020 | 20 | In Progress | Steve, Mary | 10/03/2020 | Mary | Effort |
66 | 10/03/2020 | 20 | Done | | 01/01/9999** | Steve | State, Assignees |
* Modification Date and Modification Valid To are actually date-time values (to the nearest minute) but can be shown with whatever resolution you choose. In the example table above, only the date part is shown.
** For the last modification event, the value of Modification Valid To is always set to 1st January 9999 23:59.
In this case, the Duration parameters actually calculate the difference between the last Modification Date and NOW()
A Report view that uses Historical data will have data points representing every modification event for every entity i.e. every row in the table above, and every row in the equivalent 'event table' for each entity in the database(s).
As you might imagine, depending upon how long you have been using Fibery, a historical Report may have many tens- or even hundreds-of-thousands of data points. This can make the rendering/updating of the Report quite slow. It is recommended to bear this in mind and apply date range limits and source filtering as appropriate.
Date range limits
It is possible to limit the events to include when configuring a historical report, based on a date range:
The date range can be defined using simple language terms, e.g. TODAY, PREVIOUS QUARTER, BETWEEN 10 MONTHS AGO AND 2 WEEKS AGO
Once defined, any modification event will only be included in the report if the time period between Modification Date and Modification Valid To overlaps with the Date Range.
It is not a filter applied to just the Modification Date.
So in the example above, if the report had a date filter of 01/02/2020 - 28/02/2020, then the first 4 events would be included, since they each overlap with February, even though the first modification event occurred in January.
Filtering
It is possible to applyReport filters in historical reports, just like for current data reports. These filters will apply to the events in the entities' history.
You can also add filters to the source data for historical reports, in the same way as for current data reports. See here.
When filtering the source data for a historical report, the filter criteria are applied to the current data values
Points to note
In a historical report, the entity Name field is always returned as its current (latest) value.
There needs to be a gap of at least 5 mins between modifications for them to be counted as distinct events. Similarly, any change that is quickly reverted will not get registered as a modification.
Depending on your subscription plan, there may be limits on how far back in time the modification event records are stored. See Manage your subscription for information on the length of version history available in each plan.