Adaptive card templating

Building on my previous post, the Adaptive Card Host SPA has support for card templating, which allows for the separation of the card layout from the actual data being shown.

In this mode, both cardServiceUrl and dataServiceUrl query parameters are provided when the add-in is registered. At runtime, the SPA makes requests to both URLs - one to fetch the card definition, and one to fetch the JSON data payload. The card definition can contain binding tokens expressed in the form of ${somePropertyName} that will be bound to properties in the JSON data payload. The binding of the card definition to the JSON payload happens on the client, so these URLs can refer to completely different backend services.

To use templating, register an add-in using the following URL structure:

https://app.blackbaud.com/addin-adaptivecard-host/tile?cardServiceUrl=someURL&dataServiceUrl=someOtherUrl

This more advanced use case provides some interesting options around portability and separation of duties. For example, because the card definition and JSON data payloads can come from different locations, shared card templates can be created with placeholder binding tokens, and developers can wire up those cards to their own data payloads (respecting any custom criteria or special business logic).

To illustrate how this feature can be used, I'll build two flows - one for the card definition, and one for the JSON payload (and remember that Power Automate isn't a requirement here, just an easy way for a citizen developer to build a service that returns information).

Starting with the card template definition, here is my basic flow outline:


This is essentially the same flow as before, just without all of the actions that fetch constituent/gift details. The Compose action here just builds a card template, which I pasted in from the WYSIWYG designer. You can see the binding tokens (completely arbitrary values I chose) highlighted here:


So this flow is really simplified - it just returns some static JSON string that defines the adaptive card template. The URL that triggers this flow is used as the cardServiceUrl query parameter (don't forget to URL encode the string!).

For the JSON data payload, I built a completely separate flow, which contains all the logic for fetching the constituent and gift details:


Instead of building an adaptive card definition, it just builds a very simple JSON shape (where the property names are completely arbitrary and picked by me when designing the card):


At runtime, the Adaptive Card Host SPA will combine the card definition template with the data JSON payload to produce the actual card that will be rendered in the user interface! The end result looks exactly the same as before - there's no discernable visual difference:


Templating is an optional feature of the Adaptive Card Host SPA - you can always start out in "simple mode" just building the card definition with the data embedded directly and as needs and use cases evolve, the additional flexibility of templating can be adopted.

Let us know if you're exploring how Adaptive Cards can be used on your end!