Managing Hoots
Important
Only users with the Organization Administrator privilege can manage hoots and sentries.
Hoots are the main feature that the data product users interact with. They have a 1:1 relationship with the cataloged resource. When a user clicks on a Hoot badge in their BI dashboards, a Hoot details page pops up. This small page provides the end-user with more information (link to the catalog, lineage, related glossary terms, etc).
Publishing hoots to end users
Hoots can be made available to end users by either embedding them into data product pages or through a Google Chrome extension.
Embed hoots on data product pages to make them available to end users. Users will see the hoot when they visit the specific data pages across all browsers, like Chrome, Edge, Firefox, etc., without needing any extension.
Alternatively, get users to install the data.world Chrome plugin. Post-installation, while on Google Chrome, users will see the hoot when they navigate to data product pages where hoot is set up in data.world. This approach offers straightforward management as Hoot Admins don't have to embed the hoot on every data product page. However, users must use Google Chrome and the data product link accessed should exactly match the resource page configured in data.world for viewing the configured hoots. Without a match, users won't see the Hoot badge.
For optimal user experience, it is recommended to choose only one option for making hoots available to users. If both options are active, users may encounter duplicate hoots on data product pages, particularly in the Chrome browser, which could degrade the user experience.
Important
The Hoots Chrome Extension is only available for Private instance and Single Tenant instance installations.
Influencing the status of hoots
There are different ways in which the hoot status can change:
When the status of resource is changed in the catalog. Anytime the status of the connected resource is changed in the catalog, the hoot status changes immediately to reflect the latest status to the users of the data product where the hoots are embedded.
When the status of hoot is changed manually from Hoot Admin app. A hoot admin can decide to intervene in the automatic updates to intentionally inform the data product users about a status that is not reflected by the automated updates. For example, when a hoot is sick and all the issues are resolved, it might take some time for the automated process to be informed about the latest happy status. In such cases, the hoot admin can change the status to Happy manually so that the data product users can start using the dashboards with confidence. The manual changes are over written as soon as an automatic update is received from the data source.
When you have other Sentries connected with the hoot and their status changes. When there are other Sentries connected with the hoot - the most severe status takes effect.
Table 1.Action
Sentry 1 status
Sentry 2 status
Hoot status
A new hoot with two connected Sentries are set and the status for all is Happy
Result:
Hoot is Happy
The status of Sentry 2 changes to Sick automatically.
Result:
Hoot becomes Sick.
The status of Sentry 1 changes to Sad automatically.
Result:
Hoot stays Sick as that is the most severe status.
Hoot admin manually over writes the status of the hoot to be Happy
Result:
Hoot becomes Happy because of manual over-write.
The status of Sentry 1 changes to Sad automatically.
Result:
The manual over-write is removed because of new status update on Sentry 1.
Hoot becomes Sick because that is the most severe status derived from connected bots.