Check out other articles in the C3 Series
If you've read our origin story, you know that C3 became a highlight of Knowledge 2025 with over 44,000 card scans and incredible community engagement. But what you might not realize is the complexity of the system that made those superhero avatars and seamless scanning experiences possible.
Most people interacted with C3 through the mobile app by scanning QR codes and collecting cards. What they didn't see was the sophisticated pipeline of AI processing, real-time scoring, achievement tracking, display board management, and physical printing integration happening behind the scenes.
This article breaks down the complete C3 architecture to give you the foundation for understanding how we built each component. Whether you're planning a similar project or just curious about the technical depth behind the magic, this overview will show you how all the pieces work together.
System Components: The Big Picture
C3 is a deceptively simple application. The overwhelming majority of users interact with the entire application directly through the mobile app and rarely see much else. But under the hood is a complex set of system components that are orchestrated together around a shared data model in order to bring the capabilities to life. In the initial Knowledge 25 version of the application, we divided the work into 6 core system components:
- Intake App - Service Portal based process for submitting photo and selecting an avatar.
- Mobile App - The Mobile App Builder powered app that Knowledge attendees downloaded from the Apple and Google Play stores for creating their avatar, collecting cards, and interacting with the game.
- Card Creation Pipeline - A complex system of integrations using Now Assist, Replicate AI, and a 3rd party custom web service that formed the core processes used to generate the avatars and the cards.
- Scoring & Competition Tracking - System for calculating individual and team scores, capturing scannable zones for your team, and displaying the competition results on displays around the conference.
- Achievement Engine - Rules engine for unlocking various pre-configured achievement cards during the event.
- Card Printing - A combination of two different systems enabled card stock printed cards for attendees who selected their avatars during the pre-engagement phase and a second MID Server powered process that enabled on-site printing of cards on photo paper.
One key advantage of dividing up the app in this way, is that once we decided on the shared data model, we were better able to coordinate our independent development effort by having each developer focus on specific system components. One of us could work on the intake app while another worked on the mobile app and we didn't have to worry too much about stepping on each other's toes.
Data Model: Sharing is Caring
Each of the main system components coordinated through the shared core data model. The data model was mostly designed up front but it did evolve as we built the application to solve different issues we encountered. The data model consisted of a few main tables that drove the core behaviors of the application:
Core Tables
Profile (x_snc_cctcg_photo_profile)
Each Profile record represents a player in the game. The table's design took some cues from the CSM application's Contact table with one key distinction: we referenced the User table instead of extending it. Call me crazy, but I prefer composition over inheritance.
Similar to the Contact table, creating a record on the Profile table would automatically grant the x_snc_cctcg_photo.player role to the associated User. In this way, the Profile table also acts as an Allow List for who can create avatars and play the game. This also made it easy to implement a simple data import for granting users access to the app.
It also contains a number of other data fields related to the User's ServiceNow Community profile as well as image fields for the player's card.
Photo Submission (x_snc_cctcg_photo_photo_submission)
Each time the user submits a photo of themselves to generate a new set of avatar options, a Photo Submission record is created and the image is attached to an image field on the record. The Photo Submission table inherits from task and is one of the two tables that powers the intake processes.
Generated Image (x_snc_cctcg_photo_generated_image)
The Generated Image table is the second table that powers the intake process. Where the Photo Submission handles photos submitted by the user, the Generated Image table handles the avatars created by Replicate AI. This table also inherits from task, and because it facilitates an integration with Replicate AI to handle both avatar creation and background removal, there are also fields for external IDs representing the different requests with Replicate AI.
Scan Activity (x_snc_cctcg_photo_scan_activity)
The Scan Activity table is the core table for gamification. Every time a user scans a card, a point of interest, or some other game supported QR code, it generates a Scan Activity record. One of our most important performance considerations was how do we ensure users can continue to scan and collect cards under load. Because of this, we designed the Scan Activity table to handle almost all of its Business Rules and processes asynchronously. That way, each user scan only required a single record insert and the rest of the logic was handled similar to an Event Sourcing architecture which meant the processing could catch up when the load slowed down.
Scan Activity is the core table that drives collecting, scoring, and triggers earning achievements. Anything that relates to gamification is looking at this table.
Achievement (x_snc_cctcg_photo_achievement)
The Achievement table is functionally similar to the Business Rules table in that it is a declarative rules engine. Each time a Scan Activity occurs, a script queries the list of active Achievement records and processes them to evaluate whether or not an achievement was earned via the scan. When an achievement is earned, a Scan Activity record is created for the Profile that earned the Achievement. Technically, achievements could have been implemented directly using Business Rules and some Script Includes to handle common use cases. But creating this table made it easier to administer all the rules and data related to these specialized rule sets. As a bonus, it would be trivial to add a role that grants specific users the ability to administer just the Achievements and their rules.
Supporting Tables
QR Code (x_snc_cctcg_photo_qr_code)
QR Codes enable scanning and collecting of cards throughout the system. So we needed a place to store the QR Codes we generated. This table is where all the QR Code images get stored and ultimately triggers the card creation.
Log Entry (x_snc_cctcg_photo_log_entry)
I hate the System Log. Don't get me wrong, it serves as a valuable source of information about what is going on in your application. However, when dealing with complex integrations, it can be helpful to have logs associated with the records driving the processes. To that end, we created the Log Entry table as a way to associate custom log messages with the Photo Submission and Generated Image records. This table made troubleshooting and monitoring the integrations so much easier. And it could be added as a Related List to the task records it related to.
Other Tables
There were a number of other tables that mostly facilitated drop down lists such as Team, Event, Community Badge, and QR Type. We also had a Feedback table and an Issue table to gather those coveted 5 star reviews and provide users a way to report problems they were having.
Processes: How Stuff Got Done
I really wish I could say that most of this app was done with Flow Designer. But only Kristy was a dutiful Sr. Developer Advocate while Earl and I stuck mostly to Business Rules. But this app had a lot... and I mean a lot of logic. By my count, it contained 12 Script Includes, 35 Business Rules, 4 Script Actions, 15 UI Actions, 4 Scripted REST Resources, 4 Flows, and 1 MID Server Script Include. And that doesn't cover Service Portal work, Mobile App, data imports... did I mention it was a lot of logic?
That said, there are a few core processes that most of the logic drives:
- Card Creation - This process starts with a user creating a Photo Submission record, runs through avatar creation, and ends with a digital card and in some cases a physical card being created.
- Card Moderation - This process involved a manual review of created cards to ensure work appropriate content and no trademark / copyright infringement
- Card Printing - This process involved both pre-engagement printing on card stock and on-site printing via MID Server using photo paper.
- App Operation and Support - This process involved troubleshooting and resolving user issues submitted through the app and as users came up to us at the booth.
- Gamification - This process starts with a Scan Activity and handles all of the processing related to scoring, achievements, and display boards.
Integrations: Don't Make Me Think
I think it goes without saying but there are certain things that are best left to 3rd party services and C3 is no exception. C3 extensively leveraged a number of integrations for it's core behavior and before we wrap up this high level article, I want to make note of the services we used:
- Replicate AI - We used Replicate AI models for creating avatars and removing backgrounds from the images to isolate the avatar for placing on the card.
- Short.io - We used Short.io for QR Code creation
- Custom REST Endpoint - We used a custom PHP REST endpoint to composite the final cards. This exposed a graphics utility that allowed us to combine the avatar, card background, Community Badges, and text onto the card.
- Now Assist - Ok, technically this isn't an integration, but we did leverage Now Assist capabilities for things like creating and sanitizing the card's title and description text. And since it wasn't a typical Now Assist click through the wizard and deploy to the panel, it felt like an integration. And since I'm writing the article I'm counting it.
Conclusion
So there you have a high level overview of everything that went into the CreatorCon C3 app. Yes. This was the high level overview. In future articles, we will dig into many of these components, processes, and integrations and how they work in detail. So if you think this article was a lot, wait until I start running my mouth about the Replicate AI integration.
3 Comments
