Skip to content

[Feature Request] Opt-in host-side templating expansion (Designer expands ${...}/$data; the Teams host does not) #9383

Description

@ashishchourasia1996

Problem Statement

Templating expansion is producer-side only. The adaptivecards-templating SDK ships for .NET and Node.js only - there is no JVM/Java (or iOS/Android/UWP) SDK.

The Designer expands $data/${...} at preview time, so an author sees a correct, data-bound card, but the Microsoft Teams host does not run the engine on the payload it receives.
Any templating that reaches Teams is left unexpanded: string bindings render as literal ${...} tokens, and typed/enum bindings fail strict payload validation.

This makes authoring parity misleading - verified-in-Designer is not works-in-Teams, and forces every producer not on .NET/Node to re-implement Microsoft's templating spec, including Adaptive Expressions, just to emit renderable cards.

We'll need to maintain exactly such a re-implementation on the JVM today; it duplicates Microsoft-owned logic. Teams is the surface where this blocks us.

Proposed solution

Add opt-in, host-side expansion of templating at render time - the same expand() the adaptivecards-templating SDK performs - and enable it in the Microsoft Teams host.
Start with self-contained payloads that carry inline $data; extend to a template plus a separate $root object.

Gate it behind some capability flag so nothing regresses - already-expanded or passthrough cards are untouched unless the producer opts in.

This is safe: expand() is bounded data-binding over Adaptive Expressions (no I/O, no arbitrary code) and yields a card identical to producer-side expansion that passes the same schema validation.

The docs already state the SDKs are meant to run "on the back-end or directly on the client," and the Designer already expands-then-renders in one host - so the remaining work is porting the engine into the native renderers.

Alternatives or Workarounds

Pre-expand server-side (what we do today). The producer runs its own expansion before sending, guaranteeing zero templating reaches Teams.
It works, but requires every non-.NET/Node producer to own a re-implementation of Microsoft's templating spec and its Adaptive Expressions - the duplicated cost this request removes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions