A Better Way to Say Thank You |
One evening i wanted to test ServiceNow Creator Tools and to improve the way how my collegues can recognise each otehr;
The Recognition Card application was born to give appreciation a proper place to live inside ServiceNow.
At its heart, the application does two things: it lets people create recognition cards, and it lets people send them to colleagues. Two catalog items, one complete lifecycle.
FIG. 1 — HIGH-LEVEL APPLICATION OVERVIEW
01 — Before & After
To understand why the application is designed the way it is, it helps to look at what recognition looked like before it existed — and what it looks like now.
Without a dedicated home, peer appreciation tended to scatter across informal channels: a Teams mention here, a verbal shout-out in standup there. Well-intentioned, but invisible to anyone not in the room, forgotten within days, and impossible to build on.
✕ Before
| ✓ After
|
The shift isn’t about adding process for its own sake. It’s about giving something inherently human — gratitude — a reliable place to land. Deliberately lightweight: no approval chains, no long forms, no restrictions on who can send.
02 — How It Was Designed
Three ideas shaped every decision in the application’s design.
✦ Low friction, high intentionThe form asks for just enough — a card type, a reason, a message — to make the act meaningful without turning it into a task. | ◆ Creation and sending are different jobsSeparate catalog items keep the library curated while the sending experience stays open to everyone. | ○ Governance that protects meaningThe freeze period ensures cards stay meaningful by preventing the system from being flooded or taken for granted. |
Design Principles:
- Using OOTB/Low code where possible; I threat Card as "Digital Asset" of a certain "Model" which may have its own life-circle; As the result no new tables/fields created
- Reusable widget to display for portal; Same widget can be configured to show Single/Multiple/All cards
- Flows to drive process;
- Script Include to contain Utils & scripted logic;
03 — The Freeze Period
One of the most considered design decisions in the application is something most users will barely notice — and that’s exactly the point.
The freeze period is a per-category cooldown that limits how frequently any given person can send recognition cards of the same type. Once a card has been sent in a particular category, a waiting period begins before that category becomes available again. The limit is enforced across both catalog items and surfaced inline — quietly, without blocking the form entirely.
A recognition card only means something if it can’t be sent fifty times a day.
Here’s what happens from the moment someone opens either form:
| ● | The form loads An onLoad client script fires immediately, calling RecognitionCardUtils.getRecognitionStatus() with the current user’s ID. |
| ● | Status is evaluated server-side The utility checks each recognition category against the user’s recent history and returns a human-readable summary alongside a per-category status array. |
| ● | Guidance appears inline The summary is shown as a field message directly on the Card Type field — right where the user is making their choice — so they know which categories are available. |
| ● | Frozen categories are clearly surfaced Categories in cooldown are marked unavailable. The rest of the form stays usable — the user can still send in a different category if one is open. |
| ● | Live re-check on change If the user switches their Card Type selection, the status is re-evaluated on the spot via an onChange handler. The guidance stays accurate throughout the session. |
◆ Under the hood All of this logic lives in the shared RecognitionCardUtils script include (scope: x_konl_visual_card). Both catalog items call the same getRecognitionStatus() method via GlideAjax, so freeze enforcement is always consistent regardless of which form is open. Changing the rules means changing one place. |
04 — Request New Recognition Card
This is the supply side — the place where new cards enter the world.
When no existing card says what someone wants to say, this catalog item lets a requester — typically a manager, HR, or a senior contributor — design one from scratch. They give it a name, a colour, a category, and a message. They decide whether it should go to specific named colleagues or be distributed based on a condition. Once submitted, the card enters the shared library and becomes available for anyone to send.
It’s less about filling in a form and more about adding something new to the organisation’s vocabulary of appreciation.
What you fill in
| Required | Name — What the card will be called in the library. |
| Required | Card Description — A short line explaining what this card is for and when to use it. |
| Required | Card Type — Category chosen from a dynamically filtered list. Freeze period status is shown here as a live inline message. |
| Required | Why are you giving this card? — Your reason, in your own words, kept on record for context. |
| Required | Main Colour — The card’s visual theme. Defaults to Salmon; other options via multiple choice. |
| Required | Card Content — The message that will appear on the card itself. |
| Required | Assignment Method — Choose between Named Users (explicit list) or On Condition (rule-based). The relevant follow-up field appears automatically. |
| Optional | Users — The people you want to receive this card. Shown when Assignment Method is Named Users. |
| Optional | Condition — A filter string for rule-based distribution. Shown and required when Assignment Method is On Condition. |
05 — Assign Recognition Card
This is the part most people will use most of the time — and it’s designed to feel that way.
Once the library exists, any employee can send a card to a colleague. The experience is deliberate but fast: choose who you want to recognise, pick the recognition type, select a card from the filtered library, write a short personal reason. Before you submit, a live preview shows you exactly what the card looks like — so you know you’ve chosen the right one.
No approval chain. No manager sign-off. Just one person taking a moment to acknowledge another.
What you fill in
| Required | I want to recognise — The colleague you’re celebrating, filtered to active Konversational users. |
| Required | Recognition Type — Dynamically filtered category, with freeze status shown inline. Selecting a type unlocks the card selector. |
| Required | Recognition Card — The specific card from the library, filtered to match your chosen type. Becomes mandatory once a type is selected. |
| Required | Why are you giving this card? — Your personal reason. Short is fine — what matters is that it’s genuine. |
| Optional | Preview — Auto-populated when you select a card. Shows the card image, name, and description inline so you can confirm your choice before submitting. |
◆ How the live preview works Selecting a card triggers an onChange client script that calls getCardDetails(model_sys_id) via GlideAjax. The response is rendered as an inline HTML block — card image at 220px, name, description, and italic comments — injected directly into the preview variable. You see the card before you commit to sending it. |
06 — Who Uses It and When
In practice, the application supports a wide range of recognition moments — from formal leadership acknowledgements to everyday peer appreciation.
Creating a new card
Launching a new value HR introduces a new company value and wants a dedicated card that employees can then send to colleagues who embody it. | Project milestone A delivery lead creates a launch-specific card and sends it directly to the named people who made it happen. | Condition-based distribution A manager distributes a card to everyone who completed a training programme, without selecting each person individually. |
Sending an existing card
Everyday peer recognition Someone went out of their way to help. A colleague takes two minutes to pick a card, write a reason, and send it — no approval needed. | Manager appreciation A team lead gives a formal, recorded shout-out using a company card — visible in the platform, not buried in a chat thread. | Cross-team acknowledgement Someone in Engineering thanks a colleague in Design, using a card that maps to the right kind of contribution. |
07 — A Platform That Means It
The best thing about this application is what it doesn’t do. It doesn’t require sign-off. It doesn’t send you through five screens. It doesn’t make recognition feel like admin.
What it does do is make sure that when someone takes a moment to acknowledge a colleague — genuinely, personally, with intention — that moment is captured, visible, and part of a growing record of what this organisation values.
That’s what it was built for.
Open the Service Catalog, find Recognition Cards, and send one today.
08 — Special Considerations/Issues
- We have set "Freeze period" to be 0; Limiting desire to recognise felt artificial; But we have left approval after submission for validation/corrections if needed
- You may need to adopt/update workflows properties according your needs; Things like Company Logo / Open AI API key etc.
- "New Card" Flow had idea in mind to automatically generate the card; which then to be reviewed by human; to support that there is a property which contains logo & prompt; However i was not able to achieve even close the level of output i got via chat and existing conversation. (tried variety of prompts/character sheet/sending existing card as reference... maybe you have an idea how to but i was not able to make it working for myself)
- The goal of this project was to test vibe coding and was done in a free time, so author had intention to do things right, but not to the extremum and is not guaranteed 😄 feel free to contribute & improve 🙂
⚠ Disclaimer This project is provided by Konversational (KNVL) as a free community resource to help organisations build employee recognition experiences on ServiceNow. The Recognition Card application — including all source code, configuration, catalog items, flows, and associated assets — is made available on an “as-is” basis, without warranty of any kind, express or implied. This includes, but is not limited to, warranties of merchantability, fitness for a particular purpose, or non-infringement. By using, adapting, or deploying any part of this project, you agree that Konversational (KNVL) accepts no liability for any direct, indirect, incidental, consequential, or other damages arising from your use of the project — including data loss, service disruption, security vulnerabilities, or any other issues that may arise in your ServiceNow environment. You are solely responsible for reviewing, testing, and validating this project before deploying it to any production or development instance. We strongly recommend engaging a qualified ServiceNow developer or partner to assess compatibility with your specific platform version and configuration. View the source on GitHub: GitHub Built with care by Konversational (KNVL) · Contributions and issues welcome via GitHub · Use at your own risk |
Stay Curious
