How to launch CommandBar

Philosophy of launching

To launch or not to launch, is NOT the question. The question is actually much more fundamental and nuanced. What is launching?

Launching CommandBar means several things. It can mean:

• Going live with a single Assistance experience (Copilot, HelpHub, or Spotlight)
• Going live with an initial set of Nudges
• Shipping the CommandBar library with no experiences enabled
• Going live with a full configuration that includes both Nudge and Assistance experiences

Which of these launches you pursue depends on your goals. Some common initial launch goals are:

• Testing to make sure CommandBar is installed correctly and booting for end users
• Testing to make sure that CommandBar isn't creating front-end issues for users (such as latency)
• Testing targeting/personalization to ensure that user properties (fed in via SDK, API, or an integration) are flowing properly. An example of this could be launching a single Nudge targeted towards a subset of users to ensure that the nudge doesn’t fire for all users.
• Testing an experience with a subset of users to smoke out any potential interaction issues before going live with all users. A good example of this could be launching Copilot, viewing queries that tend to produce a fallback response, and then creating content to address those queries.

Gating CommandBar

A common theme across the different launch scenarios above is restricting CommandBar access to a subset of users. This is most relevant when testing Assistance experiences (which by default are available to all users when turned on), but can also be used for Nudges (whether or not they are targeted at a user subset).

CommandBar can be launched to a subset of users without reliance on custom code or a third-party feature flag provider.

Here it’s useful to note the difference between the init SDK method and the boot SDK method. Each presents an opportunity to gate CommandBar.

1. init loads the CommandBar library on the user’s client. You can think of init as doing all the work needed to make CommandBar available to users, but all experiences are waiting at a stop sign.
2. boot turns off that stop sign, so that any available experiences become visible to the user. That means assistance experiences (and any associated launchers) appear, and nudges fire when their Who/Where/When criteria are met.

Gating init (Code Approach)

Gating init to a subset of users ensures that only that subset will receive the CommandBar library. To do this, you must feature flag the code (e.g. the snippet or a manual init call), either manually or using a third-party provider. For example

import { init } from "commandbar";

if (flag.shouldLoadCommandBar == true) {
  init(YOUR_ORG_ID);
}

When testing, some of our customers will do something like

import { init } from "commandbar";

if (user.id % 10 == 0) {
  init(YOUR_ORG_ID);
}

This will randomly init CommandBar for 10% of users.

Gating boot

If CommandBar is init for all users, you can still throttle the percentage of users that are eligible to receive experiences by gating boot in the same manner you could gate init.

if (user.id % 10 == 0) {
  window.CommandBar.boot(user.id);
}

Targeting Nudges (No Code Approach)

Another no-code approach to gating CommandBar experiences exists when you’re using Nudges only. Simply apply a targeting condition to the Who portion of all nudges that restricts access to the percentage of eligible users you wish to see your nudge.

You can either apply this condition to every Nudge manually, or create an audience that includes it.

Note that this approach will gate the users who are eligible to see the Nudge. If any other conditions are applied, then the Nudge will be restricted to 10% of the users who would otherwise have seen it.