Adaptive Card Not Working

@Bob Rickards The Method actually should be blank. When you test it with the Method field left empty, are you still not seeing the record ID come into the Flow?

Request Body JSON Schema is missing.

{

    "type": "object",

    "properties": {

        "uit": {

            "type": "string"

        },

        "context": {

            "type": "object",

            "properties": {

                "recordId": {

                    "type": "string"

                }

            }

        }

    }

}

can you confirm the application add-in URL

It should look like this

yellow highlight = base URL SPA that indicate adaptive card

green highlight following the cardServiceUrl query parameter = the Encoded URL of the trigger url in your flow

blue highlight following the title query parameter = the Encoded title of the tile

Unlike Adaptive Card where system record id is provided "automatically", Glen's AIO replies on custom JavaScript code that "insert" the system record id into the request to your flow trigger, it appears you may have broke something in the javascript code. or the logic behind the code.

Also to note, when a constituent page is loaded with AIO, it actually makes multiple calls to the flow, first call is going to go down the "default" path of the switch. 2nd flow call will trigger the "validate" path, then a 3rd call that finally display the content of the flow. So depending on when your constituen page is loading and if there is 1 run history, 2, or 3 run history, your flow is failing in different area. You will need to provide a lot more info for investigation.

The specific code is in the MainScript variable:

so first is to confirm your MainScript is still correct. (see where pieces important here in highlight)

BEFORE i type up an even longer troubleshooting steps, maybe what you need to verify is if anyone or yourselves have made changes to the flow as you said it was previously working.

I don't know if there is different version of AIO that Glen published. I also made updates to his AIO to make it more efficient for me. So this "MainScript" variable might have been me separating out the code pieces.

Your screenshot also does not look correct to me from Glen's AIO perspective. You have "Get a constituent" running every time the flow run, that would always error out. So I don't know how your tile had worked previously.

Glen's AIO logic is:

1. RE NXT calls the flow first time, which does down the "default" path of the "switch" action that loads the full HTML page to display on the tile, which at this point is "nothing" yet. This HTML contains client side (on your browser) javascript that uses SKY UX Blackbaud javascript object to obtain s UIT (User Identify Token) and the context (constituent) system record id. Then it hit the flow again providing it the UIT to validate as well as the system record id.
   1. THERE IS NO system record id of the constituent in this flow run. Your Get a constituent will fail, and therefore #2 below will never happen.
2. Run #2 in the flow, you should see the trigger request have a query property for uit and system record id. This goes down the "validate" path of the "switch" action, which uses the "Validate User identify token" action to validate the UIT. Once validated successfully, the "script" will know to load the "Loading…" content onto the tile to let user know it is now loading. the "script" then runs the flow a 3rd time to get the content to display
   1. At this 2nd flow run, you will have constituent system record id in the query. The Get a constituent would not fail (but you won't get here b/c first flow above failed already), but would also be useless to call that action
3. Run #3 in the flow is where the "real" work is done to display what you want to display. This goes down another "path" in the "switch", which I have it very different than Glen's as I have different logic that have interaction with user. You will have to look at your "switch" action looking for another path that it went down.
   1. THIS is the path that the Get a constituent action should be in.

So all that said, which gives you more context about the flow's logic. The fix "likely" just means you somehow moved the Get a constituent action incorrectly to where it is now. It needs to be moved in the the "switch" path that does the real work. If you can't figure out where that is, take a screenshot of your "switch" expanded.

A few quick thoughts

If your flow is saved in a Solution, you could use Version History to try reverting back to a version before your flows stopped failing.

Have you switched this flow over to the new trigger URL, or are you still calling it using the old one? (Does the URL in the "Add-in URL" field in your Add-in settings match the URL on your trigger in your flow?)

It is the AIO from Glen b/c I still have one that I didn't update to use Adaptive Card yet.

The ID used in the Get a Constituent is using the SystemRecordId variable, which is initialized with query parameter from trigger output

@Bob Rickards if you are going to re-do anyway, might as well change the tile to use Adaptive Card instead.