Reports can surface information from within individual event sections, including users who complete, or do not complete, assessments, time between invitation to completion, location of assessors and whether trainees and candidates are getting enough of a variation in feedback.
Fields and definitions
A new logs reporting data stream has been introduced to allow administrators to report on data in completed event sections.
Every time someone fills in a section of someone else’s event their response is captured as a log. These appear as grey entries on the timeline of the user who contributed the response.
The log data stream is extracting information from these logs.
Section reporting can be done on the Event data stream for events that are in progress, and from the Log data stream for events that are completed.
Fields and definitions
Section reporting output fields
New Output fields
Data stream | Output Property | Definition |
---|
Event & Log | Number of sections | Total number of sections contained in the Event (skipped sections are counted within the total) |
Event & Log | Awaiting section number | The section that is awaiting action |
Event & Log | Invitation date | The date a user received the invitation to complete a section. With regards to logs created by the timeline owner, this is the date at which they created the initial draft. |
Event & Log | Awaiting response from | User data of the respondee such as Full Name and email |
Event & Log | Role of respondee | Role of the respondee in regard to the section invitation. A respondee may have multiple roles. |
Event & Log | Relations of respondee | Any specified relations which were assigned to the respondee at the point of submission of the response |
Log | Time to submit | Calculates the time between event creation and submission |
Log | Respondee | User data of the respondee |
Log | Date of submission | Date the event was submitted |
Section reporting filters
New Filters
Data Stream | Filter | Definition |
Event & Log | Number of next section | Section number of section waiting for response |
Event | Awaiting response from | User data of the respondee |
Log | Respondee | User data of the user who completed the section |
Event & Log | Role of respondee | Role of the user which allowed them to submit the section |
Event & Log | Relations of respondee | Any specified relations assigned to the user who completed the section at the time of submission |
Event & Log | Role of owner | Role of the owner of the event |
Event & Log | Relations of owner | Any specified relations assigned to the owner of the event |
Event & Log | Invitation date | The date a user received the invitation to complete a section. With regards to logs created by the timeline owner, this is the date at which they created the initial draft. |
Event & Log | Date responded | Date on which the section was submitted |
Event & Log | Time to submit (in seconds) | The amount of time between receiving the invitation and submitting a response |
Event & Log | Section number | The number of the section as specified in the event type workflow |
Event & Log | Number of sections | Total number of sections contained within the event type workflow (skipped sections are counted within the total) |
Log | Event Type | Name of Event Type |
Log | Event Owner | Name of Timeline owner |
Suggested use & scenarios
Scenario: Are there respondees who are consistently blocking progression by not completing section invitations in a timely manner? Create a report showing outstanding responses for a time period.
Example report definition
Data stream = Event
Filter on incomplete events created within the desired timeframe
Report output properties
Scenario: Are trainees getting enough variation in assessment responses? Or are the same assessors always signing off the assessment?
Example report definition
Data stream = Logs
Filter and output properties
Scenario: Report on how long it takes for assessors to respond.
Example report definition
Data stream = Logs
Filter and output properties
Report view
FAQ’s
Why is Awaiting Response From “blank”
The ‘awaiting response from’ data field may be null if the event is already complete, or if the event being reported on is a goal in progress.
Why does the data on the Log differ from the Event?
In cases where an administrator has amended information on an event, the data viewable by a user in the event could be different from the log. The data in the log is a tracked history of information related to the event. Therefore, when an administrator alters information on an event, the original record is retained in the log file.
Can I use the new log data types within multi reports?
Yes, log reports can be added to multi reports in exactly the same way as Events, Users and Goals.
Why don’t the new output fields work for old event and log data?
The new functionality only takes effect for events and logs created after the release of Kaizen 2.23. This is because the data being output with the new functionality was not previously being captured and stored in a way which can be utilised by reports.