Every app in the suite now opens at rutba.io

Until 6 October, eleven parts of the suite had an address you could open: the storefront, the till, Stock, CRM, Orders, the rider app, the time clock, Books, Manufacturing, Affiliates and the sign-in page. The other 35 apps were built, but we had kept them off the server to save memory. On 6 October they joined the rest. Every app in the suite now runs in production, 46 of them counting the storefront and the sign-in page.

Each one opens at its own name under rutba.io. The till is pos.rutba.io and the helpdesk is helpdesk.rutba.io. One copy of each app serves every business that uses it.

What joined on 6 October

• People and pay: HR, Employee Self-Service, Payroll, Recruit, Workforce and Talent.
• Money and buying: Accounts and Procurement.
• The warehouse and the factory floor: Warehouse Control, Planning, Shop Floor, Quality and Maintenance.
• Buildings, equipment and the road: Assets, Facilities, Dispatch, Fleet and Track.
• Customers: Helpdesk, Marketplace and the Customer Portal.
• Content and marketing: the CMS, Social and Campaigns.
• Workspace: Mail, Docs & Sheets, Comms, Sign and Studio.
• And the rest: Deskphone, Switchboard and Voice campaigns, the Assistant, the console a business’s own administrator works in, and Seed, where that administrator loads starter records such as letter templates.

Why a business needs no addresses of its own

We could have given every business its own set of addresses, one per app, and chose not to. The suite decides whose data to show from your sign-in, and the address plays no part in that.

When you sign in, the server behind the apps looks through the database of every business it hosts, finds the one your account belongs to, and writes the name of that database into the token it gives your browser. The token is signed, so it cannot be edited to name a different one. Every app you open after that sends the token with each request, and the server answers from that database and no other. A token naming a database the server does not hold is refused.

So pos.rutba.io can serve a bakery’s till and a hardware shop’s till from the same copy of the app, and neither sees the other’s sales. Adding a business adds a database and a line in the server’s list of them. It adds no addresses, and no new copies of any app. This is the same sign-in described in one sign-in for the whole suite; the token simply carries one more fact.

The storefront is the one app that keeps a shop’s own domain. Most people looking at a shop have not signed in, so there is no token to say whose shop it is, and the domain has to say it. The server in front of the suite tells the one behind it which domain a request came to, with a key the two of them share, and the shop’s database is opened from that.

The addresses that differ from the app’s name

Links opened by people with no account

Some pages are opened by people who will never sign in. A customer follows a parcel on its tracking page. A signer opens the link in their invitation. Somebody pays an invoice from a pay link, or a candidate books an interview slot. None of them is signed in, and track.rutba.io belongs to every business at once, so the address says nothing about whose page it is.

What the link does carry is a long random token of its own. Since 6 October each kind of link tells the server how to recognise one. When a link arrives with no sign-in, the server asks each business’s database in turn whether it holds that token, and answers from the one that does. If none does, or more than one, the answer is a plain not found. The search only asks whether the token exists; the page still refuses a token that has expired or been withdrawn.

These links find their own business that way:

• a delivery’s tracking page, and the rating left on it;
• every page of a Rutba Sign signing ceremony;
• pay links;
• interview booking links from Recruit;
• shared Studio projects.

Two more joined on 8 October. One is the address another system posts to when it writes into a Comms chat channel. The other is the calendar feed a person subscribes to from another calendar app. That one needed a different test, because its signature is made with a key the whole server shares and so checks out against every business. The person it names is what tells them apart.

More joined on 9 October. A Drive share link, and the short-lived link Drive gives out for downloading a file, now find their business, and so does the public page that checks a document signed with Rutba Sign. Until then a Drive share link failed on a shared address. The careers pages (the job list and the application form) still do not find theirs. The link a job applicant uses to check on an application now does: it was fixed the same evening, after this post first went out.

Running, and still waiting for something

Some apps are deployed and open but cannot yet do their whole job, because what they need sits outside the app:

• Meetings in Comms. Rooms, the lobby, breakout rooms, polls and the whiteboard are built, but no media server is deployed, so a meeting cannot carry sound or video yet. We built the meeting and not the media server explains why it was built in that order.
• Deskphone, Switchboard and Voice campaigns. No phone system is connected. Deskphone shows an agent their own calls from the call ledger and dials nothing. Switchboard shows the numbers, the carriers and a wallboard, with no routing. Voice campaigns shows where and when calling is lawful in each market and has no dialler, on purpose. The half of a phone system worth building first has the reasons.
• The Assistant. Its screens open at assistant.rutba.io, but no model is connected to it yet, so it cannot answer a question. An assistant with no account of its own describes how it is built to work once one is.
• Drive has no address at all. Its storage is used every day by Docs & Sheets, Sign and Comms, but there is no screen of its own to put at one. We shipped the storage before the interface says what is there.

One table behind it

The script that deploys the suite holds a table with a row per app: its name, its port, its folder, its address, and the setting that carries the address into the other apps. The list of apps to build and start is worked out from those rows. So are the links in every app’s menu, and the addresses the sign-in page is allowed to send a session to.

The check we run over the whole estate reads the same table, so an app is checked from the day it gets an address. It also asks track.rutba.io for a tracking token that does not exist and expects a plain not found, which is the search above running and finding nothing.