For the last few years, Service-Catalyst has had a booth at knowledge whre we’ve demonstrated different variations of a trivia game that we built on the ServiceNow platform.  It’s a great chance to show off what we can turn around in a few weeks and chat with potential clients. We have a new twist on the concept every time and build out a game to show a taste of the endless possibilities with ServiceNow. I don’t know what it is about trivia that attracts tech folk, maybe it’s the chance to use that random fact you’ve stored away for years, or maybe it’s some deep-rooted competitive drive rearing its head. Regardless, our booth always draws a crowd and we have fun building the game for the event every year.

Before we talk about the game and how it works, I’d like to briefly run down the data structure holding everything up. The three initial data tables we use are:

– Game table: This table contains game properties like number of players and number of questions which are captured when the game is created. The two most important fields on the table are state (used heavily for gameplay mechanics) and current question number (not quite as important but is used so the game can end)

– Player table: this is used to store all the players. We leveraged it from the users table with a quick account creation that only requires name and email. We then use other tables’ reference fields to track the many to many relationships of players to games.

– Questions table: a table containing all our questions. They have categories associated with them and contain 3 wrong answers as well as the right one. These will eventually be associated to a game once it starts.

The main idea of this year’s game is a combination of trivia and gambling. We were in Sin City, so why not raise the stakes a little? Once we start a game on our big screen (jumbotron), players can join and play from any device. They choose categories then go through each question. For every question a player gets right, they get a chip to place on the roulette board at the end. If you win roulette, you win a prize.

Any player joining, simply typed the url into their browser to identify themselves to the game by logging in. ServiceNow’s url’s can get pretty long, so we utilized Bitly’s api to create a shortened url. Alternatively (and preferrably), we allowed the players to use their mobile device camera to scan a QR code to completely avoid the need for manual URL entry. Each new game that is created, triggers a business rule which uses SerivceNow’s RESTMessageV2 API. We store authentication data from Bitly in a system property to call from our script include. After getting an unhelpful 403 error for each call to the api, we finally realized the importance of Bitly’s ‘group_guid’. You can find it either by logging into your Bitly account or using postman to seek it out from the api callback but be careful, it isn’t mentioned that it is required anywhere in the docs.


Once a player logs in, their player record is associated to a game record in a many to many table and the game state is set to ‘waiting for players’. Players log in and are prompted to select up to three categories. Interestingly, when we looked back at the data after the conference, very few attendees wanted to be tested on history (it was only chosen .75% of the time). I guess people who go into tech aren’t confident in memorizing dates and details of historical events?

Once you move on from category selection, a business rule runs in the background to aggregate the categories and query the questions table for 7 random questions that align closest to all users’ choices. We chose 7 questions for Knowledge, enough for players to get invested without taking too much of their time. Once the questions are populated in the game table, a business rule is triggered to change the game state to ‘pre-question’.


The ‘pre-question’ state is used to signify that we haven’t gone through all the questions.If there are questions left to ask, a 3 second timer counts down to the next one starting. Once the countdown is finished, the state moves to ‘Question’. Users can see the question on the jumbotron and on their screens. A 10 second timer shows you how long you have left to answer. We ran the timer client side in our main view of the jumbotron and recorded answers to the database. We wrote a custom api to our player to game table since it was recording asynchronously. When the timer finishes, it records every player’s answer or lack thereof and moves to a state of ‘post-question’.


The post question state is only displayed on the jumbotron screen. There is a glide record called to show each player’s overall score so far and who got the most recent question right. This is a fun moment to watch the crowd as people realize that they actually knew answer. There is usually an audible “oh yeahhh” as about half the people ‘recognize’ the correct answer just after time expired. It then waits for the gamemaster to click to move on to the next question.



This process repeats, each time verifying how many questions have passed until all questions are completed. Once that condition is met, the state is changed to ‘roulette’. In the ‘roulette’ state, each player is given chips equal to the number of questions they got right. On their screen, they see a roulette board where they can place their chips. Once submitted, their selections are saved in their player to game record and the gamemaster can move on to the spin. We elected to use a manual roulette wheel since its more fun and trustworthy to watch it click along the wheel, willing it to land on the spaces you selected. So little technical aspect there. The gamemaster updates which spin won which triggers a business rule to mark those who selected it as a winner.

What remains is some interesting data that we collected over the conference week:

  • Out of 7 questions asked, the average correct was only 3.13. Not great but not terrible. Knowledge attendees got almost half right.
  • Our most chosen categories were Television (139), Places (138), and biology (135). Beyond that, the categories chosen  quickly fell into the 80’s and evened out around the 50’s. It’s a pretty steady decline from there reaching all the way down to that “upopular” history category,  chosen only 16 times.
  • Our roulette spins were fairly uniform except for a few outliers. Of the 12 categories players chose to place their chips, 9%-15% were winners when the wheel stopped. Two of the categories selected won an unbelievably low at 2% and 3%. Hopefully the Nevada Gaming Commission doesn’t come after us for improper wheel weighting.
  • Finally I want to give a shout out to the 12 people who answered every question right in a game. They are Rockstar trivia players! I didn’t accomplish that in the 100 times I played it in testing.