Where a sign-in should leave you: the app you hold, not a lobby
Signing in used to send everybody to the customer console, including people who hold no customer account. It now sends you to the one app you can actually open, and when you hold several, a page lays them out by organisation, with a link on every one.
· 3 min read · updated 25 September 2026

When one account opens several products, the last step of signing in becomes a question with a wrong answer available: where do we put this person now?
Ours answered it by looking at organizations. Belong to one, and you were sent to the customer console. That is right for a customer and wrong for everybody else, and it showed. Somebody whose only role is running the platform signed in and landed on a page offering an account, an organization to manage, and a way to sign out again: three things, none of which was what they held.
The shortcut is about the app, not the organization
The rule fits in a few lines. A plan you chose on a pricing page goes to checkout. The site you pressed Sign in on names a product, and if you hold its console in exactly one organisation, you go straight there. If there is exactly one thing you can open anywhere, you go to it. Anything else, and you arrive at the hub.
The hub changed with it. It used to list the apps you hold as plain text and link every organization to the customer console, which produced the worst possible page: the one app your account could open was named on screen and could not be opened from it. Now the hub is a page, organisation by organisation: what you have first (every workspace and console as a tile that opens it, a workspace with no second password since one sign-in went live) and then, for an owner or an administrator, what the organisation could add, from the price list and led by the product of the site you came from. A menu beside it lists everything you can open, and every console links back to it.
Addresses come from settings, never from a pattern
There is a tempting shortcut here that we keep refusing. Every app has a key (relay, partners, console) and it would be easy to build an address from it and hope. A guessed hostname that happens to be wrong is a broken link with our padlock on it, sent to somebody who has just proved who they are; and on a customer’s own installation, the hostnames are the customer’s business, not ours to guess.
So an app’s address is configuration. If a deployment has not been told where an app lives, that app stays a name on the hub without a link: visible, honest, and not a dead end dressed as a door. It is the same rule the whole estate follows about pages telling you what they are: say what is true, including when the true thing is “not configured here”.
A hostname guessed from an app key is a broken link with our padlock on it.
And if you were going somewhere
All of that is the answer when a sign-in has no destination of its own. Most sign-ins do: you clicked something in a console, or followed a link into the Relay, and the sign-in carries that destination through and returns you to it, provided it is on the list of places a sign-in may end, which is its own story.
The hub is what you get when nothing sent you: what this account opens, organisation by organisation, with a link on everything that has one and, if your session has ended in the meantime, a sign-in that says so rather than an empty page that looks like you belong to nothing.
One account for every Rutba site
What one sign-in covers, and what it deliberately does not.
Read the first part

