v4.0.10: Every User Gets Their Own Phone Lines and Mailboxes, and a Custom Mailbox Works Out of the Box
Two changes, and both are about handing something over: phone lines and mailboxes stop being the owner's property, and a custom mailbox stops needing a permission list before it does anything useful.
Your own lines, your own mailboxes
Until now, SIP and VoIP lines belonged to the instance owner, and custom mailboxes belonged to whoever could manage connectors. Everyone else asked.
Both are now open to every user, in Settings then Connectors, each with their own configuration.
You see only yours. A user manages their own lines and mailboxes, and can give them only to their own employees. In a chat, Phone then Line now lets any user pick a line for their employee rather than waiting for somebody with more permissions to do it.
Admins still see everything. The owner, admins and anyone allowed to manage connectors see the whole instance, and a line or mailbox belonging to somebody else is labelled with its owner, so there is never a mystery about whose it is.
Two things deliberately unchanged. Twilio numbers stay with connector managers, because they come out of the instance's own Twilio account and billing, which is not a personal thing to hand around. And the Enterprise and free tier locks work exactly as before.
If you had SIP lines before this release, they now belong to the instance owner, which is where they already effectively lived.
This follows on from bringing your own mailbox and answering on any phone provider earlier this month. Those made it possible. This makes it yours.
A custom mailbox now works out of the box
The authorized senders and recipients lists are gone for custom mailboxes. Connect an SMTP and IMAP mailbox to an employee and it simply works.
It receives every email that arrives in that mailbox, whoever sent it. It can send to any address through it. Nothing to pre-approve, nothing to maintain as your contact list grows.
Your employee's own workspace address keeps its lists exactly as before, and so does anything sent with --from-instance. That address is ours and it stays governed. The mailbox is yours.
What stops it going wrong
Removing a permission list sounds like removing a safeguard, so here is what replaced it.
It will not argue with a robot. Machine-generated mail, meaning auto-replies, delivery reports, mailing lists, newsletters and anything from a no-reply sender, is filed into the employee's received mail without waking it up. It is there if you want it. It just never triggers a response, which is how mail loops start. Robot addresses are also stripped out of the recipients of anything the employee sends.
It does not answer on its own. This is the part worth reading twice. Email arriving through a custom mailbox is marked as such, and the employee replies only when its instructions tell it to handle that kind of email.
Otherwise it writes nothing, and instead tells you briefly who got in touch, what it was about, and what it would have said.
That default is the right way round. Connecting a real mailbox to an agent and having it start replying to your customers because nobody said not to is exactly the kind of surprise that ends an experiment. You opt into autonomy here, per kind of email, in the employee's own instructions. Until you do, you get a well-briefed colleague telling you what is in the inbox.
Want to test the most advanced AI employees? Try it here: https://geta.team
