Auto-create Application/Instance when first joining FlowForge

[joepavitt]

Epic

No response

Description

User Story

As a: new customer of FlowForge

I want to: to get to an Node-RED editor as soon as possible

So that: I can quickly understand the value of FlowForge-hosted Node-RED

Objective

Reducing onboarding time from registration to user being inside Node-RED - improving "time to value"

Overview

In our onboarding UX flow, we could remove 5 x interactions/decisions that a user needs to make in the onboarding workflow by automatically generating a Node-RED Instance for them when they sign up.

If, as discussed, our time to value focus in Registration to Opening the Node-RED Editor, this would shave off minutes of time, with an Application & Instance being created at the point of registration.

source: https://www.figma.com/file/JxQe6yIm6lSIYvVi1FYCtl/User-Journeys---Calls-to-Action-(FF-Cloud)?type=whiteboard&node-id=0%3A1&t=OzOxGNqDDdCPDsvw-1

Considerations:

• The instance settings would default to the smallest instance possible, but this is enough to get started and try out Node-RED

Negatives

• Not all users want a FlowForge hosted/managed instance of Node-RED, some may just want Remote Devices
• The instance names cannot be changed, so all users would be given a starter Instance with a random name

Which customers would this be availble to

All Users, (CE)

Acceptance Criteria

• Application and/or Instance is automatically created once the user registers, confirms e-mail or signs in for the first time

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[MarianRaphael]

Ideally, based on the user data, we would initiate the automated creation of the Trial Application and Instance immediately following the automated creation of the "Team"

[knolleary]

Here's my high-level technical direction on this. It is going to clash with the work in #2519 due to how the new TeamTypes code modifies where the type of configuration is held for this type of thing.

The 'Create personal team' option in Admin Settings includes a drop-down for what type of team should be created. Once 2519 lands, we have the following admin settings:

• user:team:auto-create : boolean flag whether a team should be created when a user registers
• user:team:auto-create:teamType : hashid of the team type to create (added by Add support for multiple TeamTypes with limits/billing set per type #2519)

For this item, we should introduce a new admin setting user:team:auto-create:instanceType that identifies the type of instance to create. The list should have a none default option.

When the user picks a teamType, the list should reflect the instance types enabled for that team type.

From there, the runtime can use those flags to decide if it needs to generate the application and instance (and what type of instance to created).

• The Application should be given a sensible default name.
• The instance can have a generated name. It might make sense to generate a name from the username/team slug to avoid clashes, whilst making it bit more meaningful than the random bird names we use in the frontend.

[joepavitt]

@Pezmc how we looking for this going into 1.10? I also have #2495, but little point doing that on it's own, if this is also going to be done, as #2495 can just be done as part of this work.

[joepavitt]

Actually, ignore that. #2495 still applies when creating new applications, even outside of the onboarding UX.

[Pezmc]

This is on track to be ready in 1.10, but do note I only picked up work on it late yesterday and am still in discovery!

[joepavitt]

@hardillb was this verified yesterday? Saw some chat about it in #dept-engineering

[hardillb]

Yes this was tested on Staging, and worked once I remembered to fix the stacks in the instance types, but this is the thing I don't want to enable straight away