Enterprise products typically have two methods to organize clients:
- There is one URL for every client.
- Each client uses their own subdomain (JumpSeat does this)
JumpSeat can accommodate this in several ways.
JumpSeat groups clients into Organizations. It’s up to the product owner for what that means for grouping their own clients and applications. Each organization has a set of Users, and Applications and a URL called an Instance.
The enterprise organization is called the Authoring Org and doesn’t appear in the organization table.
An Instance denotes a URL that JumpSeat runs on. Multiple organizations can share the same instance. For this case, when interacting with an instance, we can determine which organization is the right one by looking at the User, the Application, or directly with a special parameter.
An Enterprise can set the default app type for new applications.
Segments are groups of Applications and Roles separated by App Type. While each Application has their own roles, if they have identical names, the segment will include the Roles for each Application. Segments then have selected guides and pathways pulled from the Authoring Org.
The Authoring Org uses the default Instance (control). Applications in this org should match each App Type, as they become the source of truth for guides and pathways in segments. Configuration options set in these applications become the default for Applications of that Type unless the override is set in the Organization fields.
There are several patterns that Enterprise can use to set up their JumpSeat depending on need.
The most powerful is to give each of their clients an Organization and corresponding Instance. Each of these Organizations then has an application. This is the easiest way for embedding JumpSeat because the embedded script can simply point to the instance for the Organization.
For many Enterprise products everything can be in a single Organization with a number Applications.