argus part 4: decoupling UI with adaptive cards

one of the most frustrating parts of building chat bots is the "deployment tax." normally, if you want to change a button label or add a new data field to a notification, you have to modify the code, commit, and redeploy the entire service.

with argus, i wanted to decouple the user interface from the logic. i did this by combining adaptive cards with sharepoint.

why adaptive cards?

adaptive cards are the "lingua franca" of the microsoft ecosystem. they allow you to describe a UI in a structured json format that the teams client then renders natively.

• performance: because the rendering is handled by teams, the bot only sends a small json payload.
• consistency: cards look identical across desktop, mobile, and web.
• interactivity: they support buttons, inputs, and toggle switches—essential for my "command & control" vision.

the sharepoint decoupled model

instead of hard-coding the card json inside the node.js engine, argus fetches its templates from a designated sharepoint document library.

1. centralised storage: all card layouts live as json files in sharepoint.
2. dynamic retrieval: when the engine receives a request, it checks the template name and fetches the corresponding json from sharepoint using the graph api.
3. intelligent caching: templates are cached in memory for 15 minutes. this bypasses redundant network hops while ensuring the UI stays fresh.

the benefit: zero-deploy UI updates

this architectural decision is a massive operational win. if an engineer needs to add a "severity" badge to a specific alert type, i can simply update the json file in sharepoint.

the next time argus is triggered, it picks up the new layout automatically. no code changes, no pipeline runs, and zero downtime. it allows the UI to evolve as fast as the security landscape.

in part 5, we will look at how argus uses these interactive cards to bridge the gap with itsm tools.