Insights & updates from our experts

Over the last few quarters a couple of interesting patterns have emerged amongst our larger customers who are looking to catalyze cross-team collaboration during a major incident spanning members from multiple teams.
While Teams on Xurrent IMR have remained “private” so far, ie only Team members could access the Team’s objects(Services, EPs, Schedules, Incidents etc), we are now going to provide a lot more flexibility to team admins to expose service and incident information to users outside the team, but part of the same account or organizations.
Team-level permissions
Through “Team level permissions”, Team managers can allow read-access to certain objects within the team to all other users within the organization that are not part of that specific team. For example, a Team manager can allow read-access to the escalation policies, on-call schedules and services. If someone from another team wants to know who is the on-call engineer for a service that their service is dependent on, they can go to that team’s page and easily read their on-call rosters. These permissions will also allow a team to expose its escalation policies to other teams and their incidents and services.
Account-level Roles
Account admins will now be able to create account-level “Roles”. By default, there are three fixed roles within the account - Owner, Admin and User. Custom roles allow you to define permissions that certain users can have within teams that they are not part. For example, a central Major Incident team within and organization can have read/write access to incidents within any of the organization’s team.



A Note From the Road: What SPARK Taught Me About Time
During the second SPARK event in Antwerp, I stood at the back of a training room and watched a customer build a custom integration with our new iPaaS, wiring Xurrent to another system in her stack that had never talked to it before. No services rep doing it for her. No statement of work, no project plan with a kickoff and a go-live date. Just a person with live beta access in her hands, connecting two systems by hand, and finishing it before her coffee went cold. A year ago that would have been a multi-week project with a budget attached. She looked up, a little surprised it had actually worked, and said something I have not stopped thinking about since. She said it just gave her her week back.

How Long Should ITSM Implementation Really Take in 2026?
Most vendors will tell you ITSM implementation takes six months to a year — but modern, configuration-first platforms have rewritten the math entirely. See what real implementations look like in 2026, and why a long rollout is now a choice, not a given.






.webp)





.webp)
.webp)














