Insights & updates from our experts
Xurrent® can be configured to use an organization’s existing identity provider (such as Active Directory, Microsoft Azure, OneLogin, etc.) instead of Xurrent’s own authentication mechanism to determine whether a user should be able to access Xurrent. This is known as Single Sign-On (SSO). It is even possible to configure different SSO configurations for different external organizations, so each of their users can have their own option on the Xurrent login page. The drawback of this, however, is that users have to select an option from the list of Single Sign-On configurations. And not every provider wants to show a list of their customers on their login page. This is now no longer necessary.
A ‘Settings’ section has been added to the Organization form, where a Single Sign-On configuration can be related to the organization.

At the same time, from the ‘Single Sign-On Configurations’ section of the Settings console, an SSO configuration can be related to one or more organizations. The SSO configuration is inherited by child organizations, as long as those organizations do not have their own SSO configuration.
Whenever a notification is sent from Xurrent, the links that are included in the email to access a record then include the Single Sign-On configuration endpoint that is relevant to that organization’s users, sending them to the correct URL.

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)














