# Self Reporting
Self Report is a feature that empowers users to mark skills as completed directly in the SkillTree dashboard OR through the embedded Skills Display component.
A project administrator can enable
Self Reporting for a skill, set of skills or even all the skills in a project.
Skills that have been configured with Self Reporting expose a button allowing users to self report completion of those skills.
There are four
Self report types available:
- Honor System - points are awarded immediately
- Approval Queue - request goes into the project's approval queue; project administrators can approve or deny requests. Note When choosing Approval Queue, you may also choose to require users to submit a justification when self-reporting this skill by selecting the 'Justification Required' check box.
- Quiz - a knowledge check composed of multiple questions with a passing requirement; association of a Quiz requires successful passage of that Quiz in order to earn the skill and its points
- Survey - a method to get feedback about that skill or collect information related to the skill; association of a Survey requires completion of that Survey before skill and its points are awarded
- Video - points are awarded after the configured video is fully watched
Project administrators can craft training profiles consisting of:
- only self-reported skills OR
- a mix of self-reported skills and skills that are reported programmatically OR
- a project could have no self-reported skills at all
Self reporting is enabled and configured for each skill individually. When creating or editing a skill
- then select
Self Reportingtype (
By default, Self Reporting is disabled when creating or modifying a skill.
If your project primarily consists of Self Reported skills then you can easily change the default by navigating to the
Project -> Settings tab.
There you can enable Self Reporting and select its default type for all the skills that will be created after that point.
Please see Setting: Self Report Default
To configure a Quiz-based or a Survey-based skill please select
Quiz/Survey option and then use the drop-down to locate one of
the available Quizzes or Surveys.
- Association of a Quiz or a Survey to an existing skill requires successful completion of that Quiz/Survey in order to earn the skill and its points
- A Quiz or a Survey can be associated to more than 1 skill
- Please learn more in the Quizzes and Surveys section
Please note that in order to select the
Video type, the skill's video settings must be configured.
# Skills Display
Once Self Reporting is enabled for a skill, users will see a button on the Skills Display that will allow them to report the completion of that skill.
The button's label will depend on the Self Reporting type, below is an example when the
Approval Queue type was configured.
Skills with Self Reporting can be accessed in the Skills Display component embedded within your application (via Client Libraries)
In case of Self Reporting type of
Video the configured video is displayed above the description and once fully
watched (>96%) then the skill and its points are awarded!
You could create a project that consists purely of Self Reported skills! Alternatively you can have only some skills configured with Self Reporting or no skills at all.
# Approval Queue
If a skill is configured with Self Reporting type of the
Approval Queue then points will not be awarded right away but rather go
through the simple approval workflow:
- User clicks
Begin Requestbutton and requests points
- Request appears on the project's Self Report page (see the Screenshot below)
- Project administrator approves or reject requests
# Approval History
Project administrators can can either approve or reject points/skill requests.
Approvals and rejections are documented in the
Approval History section.
Approval History tracks:
- Skill name and skill id
- Whether request was approved or rejected
- Requester's and approver's user ids
- requested and approved/rejected dates
Approval History table can be sorted by all of its columns or filtered by
User Id and/or
SkillTree will send email notifications to project administrators when points are requested, approved or rejected.
Project administrators can unsubscribe from notifications by navigating to the
Self Report page within their project.
Self Reported Skills Requiring Approval section contains a Subscribed/Unsubscribed toggle on the top-right of the component.
Please note, depending on the installation mode, an email sometimes is not available for non-admin users, in that case an email notification will not be emitted. This is not an issue in the PKI or Oauth installation modes. To learn more please visit Installation Modes section. If your organization is already running a centralized service then your POC would be able to answer that question.
# Split Approval Workload
By default, all Self Approval requests are routed to the project's approvers and administrators and they all will see the requests and will be able to approve them. All approvers and administrators will also get notifications, unless disabled of course (please see the Notification section).
If your SkillTree project has a large number of users submitting Self Report Approval requests it may overwhelm your project's Approvers. SkillTree offers a flexible way to split the Self Approval workload between multiple Approvers and/or Administrators.
- An approver can be assigned to approve requests from specific users
- An approver can be assigned to approve requests for specific skills
- An approver can be assigned to approve requests from users that have a certain user tag and/or that tag starts with a certain value (example: user's assigned org)
- Ability to designate a fallback (i.e catch-all) approver
To configure the Self Approval workload please navigate to the
Project -> Self Report and then click the
Configure button on the top right.
Please note that the project needs at least 2 Approvers/Admins in order to configure the Approval Workload.
To add Approvers please navigate to the
Project -> Access page
There are 2 user roles that can approve/deny Self Report requests, let's review:
- Admin: enables management of the training profile for that project such as creating and modifying subjects, skills, badges, etc.
- Approver: allowed to approve and deny Self Reporting approval requests while only getting a read-only view of the project.
Please visit the Access section to learn more about adding these roles.
To configure which requests are routed to an approver please click the
Edit button for that Approver/Admin.
That will expand the configuration options. Here is an example of configured skills:
Any request for a configured skill will then be routed to that approver and the remaining unmatched requests are forwarded to the fallback user (in this case implicit Default Fallback user).
The overall strategy is simple - if the request matched a setting parameter (ex. skill) then it's routed to that approver. If multiple approvers are matched, for example:
- one approver is assigned to approve requests for a skill and
- another approver is configured to approve all the requests for a particular user.
Then the requests for that skill by the configured user will be forwarded to both Aprovers:
- first approver matching by skill configuration and
- second approver matching by user-based configuration.
Pending Requests vs. History
If Split Approval Workload is configured then each Approver/Admin will see approval requests that only match their configuration.
As far as approval history goes however, Aprovers and Admins have a slightly different view. Users with an Approver role will only see the history of the requests that they approved while users with an Admin role will see the history of all the requests (it's an Admin role after all).
Even when Split Approval Workload is configured an Approver or an Admin can still turn off email notifications (please see the Notification section). Users that turn off notifications simply won't get an email but will still be able to see and approve pending requests.
Any unmatched requests are forwarded to all the fallback Approvers or Admins. Fallback can be implicit or explicit. Implicit means that specific Approvers/Admins were not specified as handlers of the unmatched request. To configure an explicit fallback user change its switch to "on":
Configuring explicit fallback users will then prevent requests from being forwarded to users without any configuration. A very simple example is utilizing this feature to configure all the requests to go to a specific Approver only, as depicted in the screenshot above.