Prepare and enable HiveOrbit¶

HiveOrbit setup establishes the rules, people, organization information and work sources needed before contribution scoring can begin. It separates preparation from the decision to start. Preparing settings does not immediately score earlier work, activate every draft or make a dashboard available to everyone.

This is a draft explanation of the newer backend setup capability. The frontend remains in progress, and its corresponding final-screen journey still needs reconciliation. This page explains decisions and outcomes; it does not establish that your organization's environment already provides the setup controls. The existing administration guide covers the previously inspected design journey.

Responsibility and access¶

An authorized organization administrator makes the setup decisions. They need an active account, a verified email address, current membership with HiveOrbit access, and permission to manage HiveOrbit configuration. A product licence or a management job title alone does not grant that permission. The setup administrator does not first need an employee score or an employee projection to exist.

The administrator should agree the purpose of the measures with managers and executives, establish role expectations, and explain the recognition audience to employees. Setup does not choose employment outcomes, purchase licences, pay campaign benefits or establish that every work activity is measurable.

Ordinary authorized HiveOrbit readers can receive setup status without receiving its management actions. A changed account, organization status or product entitlement can prevent a previously permitted operation, including recovery of its earlier response.

Preparation preserves existing choices¶

For a new configuration, preparation can install the standard scoring model, recognition catalog, their compatible pairing, neutral scoring priorities and a private recognition default as drafts. It also requests synchronization of organization information. An installed draft is not an enabled feature.

Preparation preserves existing versions, history and independently authored drafts. It does not silently replace an organization's settings or take ownership of them. Missing or incompatible existing configuration may therefore need diagnosis instead of another preparation request. Repeating preparation is not a reset.

Before first activation, setup supports prepared role expectations, assignments for active people with HiveOrbit access, and recognition visibility. An assignment can use a role prepared in this setup or an applicable published role. Existing independent, historical or scheduled assignments remain under the normal configuration process. After an activation has been recorded, including a scheduled start later cancelled, further configuration uses the normal controls.

Role expectations and recognition rules are explained in Configure contribution and recognition. Preparing them is a business decision: a saved assignment is not proof that evidence has arrived or that a score has been calculated.

Choose role expectations and the recognition audience¶

A prepared role needs a name and a comparison-group name. Choose the kinds of work it is expected to contribute, which expectations are required, the supported complexity levels, contribution dimensions and collaboration expectations. At least one work expectation must be required. Required dimension weights must total 100%; a benchmark such as response time or completed work can be left unset, but cannot be negative when supplied.

Most work categories are predefined. A people-service work expectation instead needs the organization's category name, using at most 200 characters after trimming surrounding spaces. That name must describe the actual work category used by the organization. Saving a new name does not create a work source or prove that matching evidence will arrive. Comparison-group names should be agreed consistently: case differences can identify different groups.

Setup can edit its own draft roles. Applicable published roles can be selected without making them editable in setup. Eligible people are offered with their current assignment where available; an inconsistent assignment history needs support. Assigning a role does not give the person a licence or management permission. Readiness is checked again for the proposed start, so the current list alone cannot establish future eligibility.

Recognition visibility supports private, team, department and organization audiences. Private remains an allowed fallback, and the default must be one of the allowed audiences. Separate preferences cover high-impact contributions, team achievements and cohort achievements. Setup can revise its own draft policy; an existing published policy remains governed by the normal configuration process. Review the recognition access limitations before relying on a setting as proof that every display enforces that audience.

What readiness checks¶

The supported source contract must also be available. Activation reviews applicable configuration and people at the proposed start, so being ready now does not establish readiness for every future date. An empty chart, a connected service or the absence of an error is insufficient evidence of readiness. Work-source synchronization does not promise an immediate score for every employee or prove that the business meaning of every source record has been independently reviewed.

When organization or people information needs attention¶

An account, its sign-in identity and its workforce profile describe different parts of the same person's access. Setup needs those records to agree, together with the applicable HiveOrbit licence and role expectations. A licence alone cannot repair a missing employee relationship, and assigning a scoring profile does not grant product access.

A workforce profile with no active Workforce role does not yet provide the employee information needed for scoring. The person can still remain in the organization hierarchy, so setup may require attention even if that person is not licensed for HiveOrbit. Ask the administrator responsible for workforce records to review the actual role and profile; do not create duplicate profiles or placeholder roles to bypass the check.

The reporting hierarchy must also be consistent. A manager may be needed to explain the structure even when that manager is not a licensed scoring participant. Missing managers, conflicting employee records or an unresolved organization root need correction. A genuinely empty workforce is different from missing synchronization: it can be valid when its organization and empty source results are verified.

Beginning preparation does not require the setup administrator's own employee projection to exist. Enabling scoring still requires the full applicable organization and licensed-participant checks. Resuming an interrupted initial synchronization preserves its original baseline and established snapshots. Conflicting snapshots or invalid source history need support; repeated preparation is not a reset and cannot safely erase the conflict.

Understand the setup status¶

A pause label alone does not identify who paused HiveOrbit or why it is unavailable. The service can use the same broad unavailable state when organization settings cannot be read. Support needs the actual requirement or failure information.

Choose when scoring may begin¶

The administrator can choose an immediate start or a future business date and time. An immediate start uses the decision time and does not require it to fall inside working hours. Both choices still require the other activation prerequisites and cannot begin before the organization synchronization baseline.

A future start uses the organization's existing headquarters timezone, working hours, breaks and holidays. The time must be later than the decision, inside exactly one working period for that weekday, outside a break, and not on a holiday. The end of a working period is excluded. A local time that is skipped or occurs twice during a timezone clock change is rejected; a different unambiguous time is required. Setup does not invent missing working hours or change the organization's timezone.

The start defines the earliest eligible occurrence time in that activation period. Starting now is not a request to score all earlier work. Processing and dashboards can lag the start; retained evidence must still pass the processing checks described in source processing and recovery.

Pause and begin a later period¶

Pausing an active period closes it at the pause time. Pausing before a scheduled start cancels that start without creating an active interval. The prior settings and recorded activation history remain; cancelling a schedule does not undo published future configuration.

Starting again requires a fresh review and an explicit activation decision. It is not the preparation action for resuming synchronization, which is available only before the first activation. Repaired access or a restored licence alone does not reopen a period that was suspended. A later period also does not make the gap between periods eligible for scoring.

When replacing a cancelled future start, applicable configuration may still have its original future effective dates. The new decision must pass readiness at its chosen start. Do not assume that cancelling a start has reset those dates or made an earlier start possible.

Organization-status history can also close a period at an earlier effective interruption, even when the information arrives later. A scheduled start inside the interruption can be cancelled; a later reviewed start outside it remains intact. A temporary failure to retrieve authority is different from confirmed loss of access. See organization access interruptions before treating an unavailable status as a permanent pause or assuming restored access resumed scoring.

Resolve an interrupted decision¶

The service retains the acknowledgement of a completed setup decision. If a response is lost, a compatible client can recover that same decision instead of making a second one. The original request must retain the same administrator and intent, and current authorization is checked again. An old acknowledgement describes that decision; it does not replace a fresh status review.

If settings changed while they were being reviewed, refresh the current setup information before making a new decision. Do not repeatedly submit changed choices as though they were the same request. Ask support when the available interface cannot distinguish a lost response from a new decision.

Before asking for help, retain the organization, attempted decision, chosen time and timezone, visible requirements, error wording and any safe request reference. Never include passwords, session tokens or private employee evidence in a general support message. Support should distinguish an access issue, stale review, missing synchronization, conflicting configuration and an interrupted saved response; each needs a different resolution.