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 10 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