Adaptive Card is Blank

@Wendy Bondeson
First thing to check as debugging your flow is to check the flow run log.

in the flow (not editing), check to see when you think the adaptive card is supposed to have trigger that if there is a “run” for that date/time. If you don't see it, then you have a triggering problem, which means when you create the “URL” for the Add-in in developer application area, you made some mistake there.

if you do see run log, click on the date/time, it will take you into the flow run, and tell you where the flow may have failed or if not failed, what response was sent to RE NXT.

@Glen Hutson
Oh yes, the obvious/yet not so obvious one, make sure the flow is turned on.

I think we all do it from time to time

@Wendy Bondeson @Alex Wong

This was my shared template for the address card. I asked Wendy to look at the JSON script to make sure it was kicking off the 2nd part.

I put a Read Me note in the flow that says: At the end of the "Compose-JSON Card Script" there is an "Action.Webrequest" that requires the AppID from the second flow that you need to create. I made it a variable below if you want to try to put your URL into that string called "AppID from Flow to Invoke It". At the bottom of the Compose JSON is this where I have the ApplicationID as a string variable.

"actions": [
{
"type": "Action.Webrequest",
"title": "Submit Your Updates to CA Records",
"url": "@{variables('ApplicationID')}"
}
]

My real one looks like this- with some # signs I put in to disguise some of the numbers

"type": "Action.Webrequest",
"title": "Submit Your Updates to CA Records",
"url": "https://prod-155.westus.logic.azure.com:443/workflows/#########/triggers/manual/paths/invoke?api-version=2016-06-01&sp=/triggers/manual/run&sv=1.0&sig=ceF8uD4jae8RHxnTdB2PQuEHwwzxot-fKK5fYxMMVOc"

Wendy- I recommend reading this blog and part 2

@Wendy Bondeson
I only build Adaptive Card for displaying custom content. I do not use Adaptive Card for submission and processing as the way Adaptive Card support is now is too limiting. I use modified version of Glen AIO that's somewhat more high code but has higher level of control.

Will see if others who have done the submission help, or @Ben Lambert can help (author of the post linked by Carol).

@Wendy Bondeson
if you are failing the validation, but your flow “mostly” is working as designed, that sounds to me like you are not validating first.

First NOTE: The general process for HTTP triggered flow is to validate the UIT (user identity token) before you do anything else, this is for the “just in case” situation where some malicious entity got a hold of your HTTP trigger URL and mess with your database.

2nd NOTE: the reason why your UIT validation is failing is likely b/c of timing, UIT is not valid forever. I don't know how long the validation “stays valid” though. So if someone went to the constituent page (assuming this is where you loaded your custom adaptive card tile), and left the page sitting on the browser (say 1 hour), and then use the adaptive card to submit the form, at this point the UIT is no longer valid.

Generally, what you can do is when UIT validation fail, you can send back a message telling the user to reload the page they are on and retry. But I'm not sure if Adapative card has that ability to send back a custom message.

@Wendy Bondeson @Alex Wong @Carol Grant

I wanted to chime in with a few clarifying points:

Regarding the UIT expiration - in the Adaptive Card Host SPA (also true for the add-in framework in general), a UIT is fetched on-demand from the host application when needed before invoking any web requests. So in Alex's 2nd note, even though the user sits on the page for a long time before clicking the Submit button on the card, the UIT will be fetched when the button is clicked. The UIT sent to the specified URL (i.e., your second flow) will be "fresh" and not expired.

Regarding UIT validation - Alex's 1st note is correct. The UIT validation step is an important protection again someone manually triggering your flow and should be done before any “real” logic in your flow. As mentioned in the docs, SKY Add-in URLs are visible in the browser including any query params (like your flow's URL which itself contains embedded keys for triggering the flow). Because of that, the add-in URLs can't be treated as sensitive (since any user can technically see them), so you have to compensate by validating on the server. The UIT is issued to "your SKY application", so the Validate UIT step protects your flow real logic from being executed if the flow were ever triggered with a UIT issued to a different SKY application.

So - Carol, you should NOT add an input to your flow to accept the application ID - that defeats the security mechanism (since anyone could call your flow with their UIT and an arbitrary application ID). Your flow should validate that it was triggered with a UIT that could only have been issued to your application. So you should hard-code the expected application ID in each flow, not allow it to be provided by the caller. The Validate UIT step validates the signature of the UIT (was it signed by Blackbaud, has it expired, does it have the right data elements), but it also compares the application ID in the UIT with application ID you expect. So this step ensures that your flow logic will only be executed if the application ID in the UIT matches the ID that you expected when authoring the flow.

(note: the application ID itself isn't sensitive, it's the OAuth client ID, which is just a guid, and is visible in the address bar of the browser).

Hope this helps!