In this article
Albato ships changes to the embedded iPaaS your product sits on, and most of them you never have to think about. This batch is different in one respect. The November interface update reaches every client at once, it arrives inside your iframe together with the platform, and there's no way to opt out of it.
The rest is optional and useful. Teams turns a single user into a workspace with spaces and roles. The interface language is now something you maintain yourself, in your own terminology, over the API. Two smaller builder changes round the release out.
None of it asks you for integration work. What November does ask is that someone on your side looks at the new screens before your users do, and that your documentation catches up.
What changed:
- Every one of your users gets the new interface in November
- Your users get workspaces and spaces instead of one account
- The interface in the language of your market
- Two smaller changes in the builder
- What this asks of you
Every one of your users gets the new interface in November
In November the Albato interface is updated for every client: platform, embedded and white label. For you that means the new screens land inside your iframe together with the platform. There's no separate release to schedule, no addresses change, and staying on the old interface isn't an option.
What we check on your project before the rollout
Before the rollout we go through every interface change against your project: your screens, your copy and your iFrame settings.
Your help center screenshots will go stale
Screenshots in your own help center that show the Albato interface will need refreshing once the update lands. That is the one piece of work November creates for you. We can reshoot those screens on your stand so your documentation matches what your users see.
Your users can hand an automation to someone by link
An automation link can now be passed to another person. A new user registers through the link and gets the structure right away, and an existing one copies it into their own account.
The author opens "Share" in the automation card menu and gets a window with the automation name and ID, the link itself, "Copy" and "Refresh link" buttons and a short markdown description. Refreshing the link stops the old one working, which is what you want when it went to the wrong person. If the automation uses private apps, the window warns that the recipient needs access to those too.
On the receiving end, a signed-in user sees an import screen, and a new one registers first and then imports. After the import the automation editor opens. The structure is copied without connections and custom fields, and the copy doesn't sync with the original.
Data that passes once when a field changes
The "changed to" filter hands your users control over the automation memory. Data passes exactly once, at the moment a field takes the value they asked for. A deal goes through once when its status becomes "in progress" and stays quiet after that, even if the status changes again later. It covers the "entity status changed" scenarios where the source system never emits such an event of its own.
Six more changes your users will meet
The rest of the update is smaller, and your users will run into all of it:
- Drafts instead of empty automations. "Create automation" no longer drops an empty automation into My automations. It stays a draft until at least one step is added, in linear and pro mode alike.
- A new step picker. The windows for adding actions and tools were rebuilt on the new design, and every step of every automation goes through them.
- Automations as a list. My automations now has two modes, cards and a compact list.
- Global webhooks without a pointless window. Some apps use a global hook, one address for all of Albato. The interface no longer shows those apps a hook settings window that doesn't exist for them.
- Stickers on the canvas. Notes sit right on the automation diagram and can be created, edited, deleted and dragged. Pro mode only.
- The line to the "Webhook response" step. It's back on the canvas, drawn as a dashed line.
Two of those are visible enough to be worth a look before your users get there. Here is the list mode in My automations:
And here is a sticker on a pro-mode canvas, sitting next to a Google Sheets trigger, a Filter and an Add action step:
Your users get workspaces and spaces instead of one account
Teams replaces the single user with a structure. The workspace is the company, and it splits into spaces: departments, or one space per client if your user is an agency. Each space carries its own automations, connections, builder apps and solutions, with folders inside. Workspace ID and space ID are visible on the automations page.
Roles per space and a plan that belongs to the workspace
A user holds one role at workspace level and a separate role in each space, so the same person can be an admin in one space and read-only in another. The plan belongs to the workspace rather than to a user.
For an agency that means a client is run in their own space, sees only their own work, and keeps the automations when the engagement ends.
Seats come from the plan: 5 users on the Teams plan, 1 (the owner) on Free, Trial and legacy plans, and whatever the plan configuration says on Custom. Going over the limit gives the user a clear error with the option to remove someone or move up a plan.
What Teams looks like inside your iframe
Teams is switched on at contract level and works inside your iframe. If it's open on your contract, it's available on every plan under that contract.
A white-label user can be added to a space through the API with no email confirmation, so the signup flow you built stays the way you built it. The impersonation link in the Embedded Portal respects workspace and space.
The interface in the language of your market
The interface language isn't something you wait on us for any more. You hold the keys and the wording, in the terminology your market actually uses, which matters if you ship Albato as a white-label integration layer under your own brand.
Key and translation tables you maintain yourself
Key and translation tables are served over the API and can be downloaded with a button in your embedded account, separately for frontend and backend. The usual path is to run an automatic translation over the table, proofread it, and from then on maintain the keys yourself.
New translation keys land in that table automatically, so new functionality ships with translations instead of waiting for them.
Builder app fields in all 7 languages and Polish in the picker
Field names and hints of builder apps are translated into all 7 Albato languages, not only the ones the app author picked. The order is the author's translation first, then the automatic translation, then English.
Polish was added to the interface language picker, with English as the fallback. Interface only, not the website.
Two smaller changes in the builder
Connection lists refresh themselves. Opening a field window pulls the lists automatically, with no click on "Update". The spreadsheet and sheet fields of Google Sheets are the clearest case, and the same mechanism covers lists in other apps' connections.
Static custom fields work inside line sections. A set of static custom fields, where the user types the keys by hand because the field set is not known in advance, was previously available only at action or connection level.
What this asks of you
Nothing in this release needs integration work from you. November is the only part of it with a date attached, and before the rollout ask your Albato manager for two things: the pre-rollout check of your project, and the reshoot of your help center screenshots. Teams and the interface language you switch on when they fit your roadmap.
Everything else in this release is in the companion piece, What Albato 2.0 Gives Your Product, Your Agent and Your Team.
