Concurrent Sessions - Exploring System Properties You Didn't Know Existed
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
19m ago
If you find this content helpful please upvote, thank you.
Imagine I own a library. I have shelves full of books, and of course, I want people to borrow them. That's the whole point of having a library. So, I give every member a library card. Now imagine one of my members comes in on Monday and takes a book home. On Tuesday, they come back and take another one — without returning the first. Wednesday, another book. Thursday, another. And by the end of the week, they have seven books sitting at home.
Now, is borrowing seven books wrong?
Not really.
But as the person running the library, I have another question to think about: What about everyone else who wants those books? I don't want to stop people from borrowing books altogether. After all, if I tell everyone, "You can borrow only one book at a time," my library probably won't be very useful.
So instead, I come up with a simple rule: Each person can borrow a maximum of three books at a time. You can borrow one. You can borrow two. You can even borrow three. But once you've reached three, you need to finish and return one before you can take another.
And that's where I started thinking about something very similar in ServiceNow.
What if we looked at sessions like books in a library?
In this story, the library is my ServiceNow platform, and the books are the active sessions.
A user can have more than one book at a time — just like a user can have more than one active session.
For example, you log in to the same ServiceNow instance using:
• Chrome.
• A Chrome Incognito window.
• Microsoft Edge.
• Or even another browser session.
Same instance. Same user ID. Same password.
Every time you establish a separate login, you are creating another session. And as the platform administrator, I am essentially the librarian. I have visibility and control over how I want to manage these sessions.
Now comes the real question...
Can I put a limit on how many active sessions one user can have?
And if yes...
How many should I allow?
Luckily, our ServiceNow platform already gives us two properties that answer these questions. The first one, glide.authenticate.limit.concurrent.interactive.sessions, answers the simple “Do I want to put a limit?” question. It is a True/False property — set it to true, and we are telling the platform, “Yes, I want to enforce a limit on how many active sessions a user can have.” Set it to false, and there is no concurrent session limit being enforced.
But then comes the second question: “If yes, how many?” That's where glide.authenticate.max.concurrent.interactive.sessions comes in. This property lets us define the actual number of active sessions we want to allow — it could be 1, 2, 3, or whatever limit makes sense for our requirement.
Now, what happens when the user reaches the limit? Let's say we have configured the maximum as 3. A user already has three active sessions and then logs in again, creating a fourth session. In our library, the librarian doesn't simply say, “You already have three books, so you can't borrow another one.” Instead, the oldest borrowed book is returned, and the user can take the new one. Similarly, when the concurrent session limit is reached, the oldest active session can be terminated to make room for the new session. So the user can continue with the newest session without exceeding the configured maximum.
Now it's your turn to play around with it! Try changing the values, observe how the session behaviour changes, and see what pattern you notice.
We also tried an interesting use case during our exploration — allowing up to 3 concurrent sessions for administrators, while limiting other users to just 1 session. That's another scenario you can experiment with and see how you would achieve it in your own ServiceNow instance.
If you've used these properties in your development or come across an interesting use case, I'd love to hear about it.
