How do I roll the new builder out to my users?

What changes for your users when you turn on the new builder, what stays the same, and how to sequence the rollout.

Nothing changes for your users until you ask for it. An integration that creates a course without specifying which builder to use gets the Classic builder, exactly as it does today. The new builder is opt in, so your application has to request it explicitly before any of your users see it.

That gives you control of the timing. You decide which of your users get it, when, and whether they get a choice.

What stays the same

• Existing courses. Every course already built stays where it is, opens in the Classic builder, and keeps working as it does today.
• Your integration code. Course and screen ids do not change, and the course embeddables behave as they did.
• Learner access. Existing links, embeds and SCORM packages keep working.
• Reporting. Analytics and tracking are unchanged, and history is intact.

What your users will notice

• Screens are made of blocks on a six column grid rather than chosen from fixed screen types. A screen starts from a layout and can be rearranged afterwards.
• Courses group into sections, which learners see as chapters with their own progress.
• The agent sits in the builder, so a user can ask for a screen, a section or a rewrite at any point rather than only at the start.
• The learner view is rebuilt for courses built this way, with one button driving progression, a progress bar, a course outline and a resume prompt.

A course lives in the builder it was made in, so a user who starts a course in the new builder stays there for that course, and their older courses stay in Classic.

How should I sequence it?

There is no single right answer, but the sequence below keeps the blast radius small.

1. Try it yourself first. Build a real course end to end in the new builder, in your own tenant, before any customer sees it. Most of the questions your support team will get are answerable in ten minutes of building.
2. Pick a small group. Enable it for a handful of tenants whose users build often enough to give you feedback quickly.
3. Decide what your users see. Because the choice of builder is yours to make per course, you can offer it as an option, make it the default for new courses, or hold it back entirely. You do not have to expose the choice at all.
4. Brief your support team. The two questions worth pre-answering are what happened to screen types, and whether existing courses change. The answers are that layouts and blocks replace them, and no.
5. Widen it. Once the group is comfortable, extend it to the rest.

What should I tell my users?

Lead with what they can do rather than with what has changed. The three things that land are that a screen can hold whatever the content needs rather than one kind of content, that a long course can be chaptered into sections, and that they can ask for changes in plain language instead of rebuilding by hand.

Be clear on one point up front, because it is the question that generates tickets: their existing courses are untouched and stay in the Classic builder.

Frequently asked questions

Can I let some users have it and not others?

Yes. The builder is chosen per course by your application, so you can scope it however you like: by tenant, by user, by a flag of your own, or by nothing at all.

Will my users lose anything by moving?

Hotspot is not currently available as a block. Hotspot screens in courses already built in Classic are unaffected and keep working.

Do learners need to do anything?

No. Learners see a course, the same way they always have. Courses built in the new builder have an improved navigation experience, and anyone partway through an existing course is unaffected.

Can a user move an existing course into the new builder?

No. A course lives in the builder it was made in, so a user who wants a course in the new builder starts it there.