Looply Academy
  • Getting Started
    • What is Looply?
    • Deployment Models
  • System Requirements
  • SAP Integration: ABAP Add-on & Access
  • Security & Identity - What IT Teams Need to Know
  • Authenticating Teams User Actions to Enterprise Systems
  • Signing Up & Onboarding Your Team
  • Looply Implementation Plan
  • Looply Integration Demos
  • Integrations
    • Microsoft Integration
    • SAP Integration
      • Installing the ABAP Looply Add-On
        • Gateway Service Setup - Single System
        • Gateway Service Setup - Hub scenario
      • Triggering or Resuming a Looply Workflow from SAP
      • Triggering SAP code from Looply
      • SAP Workflow Integration
      • Varo/Stelo Integration
      • SSL & IP address
      • SSO Authentication
  • App Management
    • Building Apps
    • Deploying apps to Teams App catalog
      • Looply Dashboard
      • Manual Installation
    • Installing Looply Apps
    • Uninstall/Update Looply Apps
    • Teams Admin center
  • Adaptive Cards
    • Building Adaptive Cards
      • Container Elements
      • Content Elements
      • Input Elements
      • Actions
    • Data Binding
    • Conditional Rendering
    • AI Assistant
    • Inline Functions
  • Workflows
    • Building Workflows
    • Triggering Workflows
    • Environment Variables & Profiles
    • Versioning Workflows
    • Using HTTP Requests
    • Using Functions
    • Using Conditionals
    • Using Branch Conditionals
    • Using Advanced Conditionals
    • Using Integrations
      • Adaptive Card Actions
      • SAP Requests
    • Using Redirects
    • Using Override Payload
    • Terminating Workflows
  • Data Vault
    • Variable Datastores
  • Monitoring & Logs
    • Monitoring Workflows
    • Error Notifications
  • API REFERENCE
    • Developer API Overview
    • Workflow API
    • Adaptive Card API
  • Team Management
    • Managing Organisations
    • Team Roles and Permissions
  • Resources
    • JavaScript Libraries
  • Tutorials
    • Creating MS Teams Apps
    • Designing Workflows
    • Building Adaptive Cards
    • Adaptive Cards with AI
    • Examining Workflow Executions
  • Support
    • Changelog
    • Contacting Support
Powered by GitBook
On this page
  • Overview
  • Conditionally Rendering an Error Message
  • Logical Operators
  • Prebuilt Functions
  1. Adaptive Cards

Conditional Rendering

Render select elements depending on the cards current data payload.

PreviousData BindingNextAI Assistant

Last updated 9 months ago

Different Payloads will be used against adaptive cards depending on the results from the previous states within a Looply Workflow. Different results may require you to change the card to accommodate these changes. e.g. an error message from a previous state in the Looply Workflow.

Note: Using the is the easiest method to write the logic for conditional rendering.

Overview

Each element has an "Only show when" attribute which is rendered as the $when attribute in the . If this attribute is true, will display the element.

Each element has an "Initially Visible" attribute which is rendered as the isVisible attribute in the . If this attribute is true, will display the element when the card first loads. We will not go into detail with this option as it is not as powerful as the $when attribute as described above.

Adding a condition to trigger a true or false value for the $when takes principles described in the section and standard logical operations commonly seen in programming languages such as JavaScript.

Note: Due to the conditions being written in a JSON format they need to be encased in a string. Checking if a string equals another will require you to use \ to escape the quotes special character.

Conditionally Rendering an Error Message

If you were to get an error from your Looply Workflow. We may need to display a red banner and a message about what has gone wrong. But we should only display this if we get an error otherwise we should display a success message.

An example payload from a Looply Workflow could look like the following:

{
    "httpRequestSAP_1": {
        "output": {
            "headers": {
                "www-authenticate": "Bearer realm=\"SAP NetWeaver Application Server [GW1/100]\", error=\"invalid_request\", error_description=\"Both, OAuth 2.0 token endpoint and resource server require usage of TLS 1.0. Caller used HTTP instead of HTTPS\"",
                "set-cookie": "sap-usercontext=sap-client=100; path=/",
                "content-length": "0",
                "content-type": "text/html",
                "sap-server": "true"
            },
            "data": "CSRF Token fetch failed",
            "status": "400",
            "statusText": "Bad Request"
        },
        "description": "SAP Update"
    }
}
{
    "type": "AdaptiveCard",
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
    "version": "1.5",
    "body": [
        {
            "type": "Container",
            "items": [
                {
                    "type": "TextBlock",
                    "text": "SUCCESS",
                    "wrap": true
                }
            ],
            "style": "good",
            // render the success message if the status does not equal 400
            "$when": "${$root.httpRequestSAP_1.output.status != \"400\"}" 
        },
        {
            "type": "Container",
            "items": [
                {
                    "type": "TextBlock",
                    "text": "ERROR - ${$root.httpRequestSAP_1.output.data}",
                    "wrap": true
                }
            ],
            "style": "attention",
            // render the error message if the status equals 400 or 500
            "$when": "${$root.httpRequestSAP_1.output.status == \"400\" || $root.httpRequestSAP_1.output.status == \"500\"}"
        }
    ]
}

Logical Operators

As described above, the logical operators that are available are similar to those found in some programming languages. Below is a list:

Operator
Operation

&&

AND

||

OR

\

Escape Special Character

!=

Not Equals

==

Equals

Prebuilt Functions

We want to conditionally render the message at httpRequestSAP_1.output.data if the status is 400 or 500. Below is an example of the card payload from the to make this happen:

All conditions are encased in ${} much like that of .

Note: Similar to the binding in the section. We can only see the result by testing the card using the Test Card action in the View menu from the .

You can make use of a number of prebuilt functions in your conditional rendering logic. For more information, visit .

data binding
this link
Check out Chapter 9 of our Building Adaptive Cards tutorial!
Data Binding
Card Payload Editor
Card Payload Editor
Card Payload Editor
Card Payload Editor
Card Toolbar
Binding JSON Arrays