Enhancement Request: Enable Interactive Custom HTML Widgets

General
1

Howdy Again,

@Veronique_Cadet @brittany :smiley:
A Note : I am not a developer, but I try to be concise, i hope this makes sense.
I’ve identified a functionality issue with our custom HTML applications. When deployed standalone on a public domain, our code is fully functional.
However, when the same code is embedded within the Portal as a manually assigned custom app, its features are restricted and fail to execute correctly.

This appears to be a classic parent-child sandboxing issue, where the portal’s security policies are limiting the embedded code’s capabilities."

image
image1024×1024 71.7 KB

The Goal:

We need the ability to embed rich, interactive HTML widgets into the portal that feel like a native part of the platform.

To achieve this, we request two core capabilities:

Dynamic Personalization (“Smart Tags”): The ability to insert simple placeholders into our HTML (e.g., {{user_name}} or {{account_id}}) that the portal automatically replaces with the current user’s live data. This allows us to create a personalized experience for every client.

Secure Actions & Data Flow (The “Bridge”): A secure way for our custom code to communicate with the portal. This would allow our widgets to:

Tell the portal to perform actions (e.g., “save this data,” “show a success message”).

Ask the portal for information (e.g., “get the latest report data”).

The Benefit:

Implementing this will allow us to build fully integrated tools—like custom dashboards and interactive forms—instead of just displaying static content. This creates a seamless, powerful user experience without ever compromising the portal’s security, as all actions would be managed safely by the portal itself.

Christian TenEyck, EA

TenEyck Business Services

Solutions for Small Business

A: Jersey City, New Jersey USA

e: Christian@TenEyckBusinessServices.com

D: (732) 266-7768

2

Hey @Christian_TenEyck_EA thanks for the ping and detailed explanation! Super helpful context :slight_smile:

From what you’ve described, it sounds like the issue isn’t with the Assembly portal itself, but rather with the behavior of the embedded iFrame content. When third-party or custom HTML apps are embedded, the permissions and functionality are governed by the originating tool or site, not by Assembly. In many cases, iFrames are configured by their source to be read-only or to block certain actions for security reasons.

If you can share the content or code snippet you’re trying to embed with our team at support@assembly.com, we’d be happy to take a closer look and confirm what’s happening in this case. While we can’t modify the originating tool’s capabilities, we can help identify what’s being restricted and see if there are any available workarounds.

Appreciate you flagging this and taking the time to outline your goals for more dynamic personalization and data exchange! You always have such helpful and detailed requests which really help our team :sparkles: