--- title: DaVinci user interface options description: There are two options for DaVinci-rendered user interfaces in a flow: component: pingone-api page_id: pingone-api:davinci:getting-started-with-davinci/ui-options canonical_url: https://developer.pingidentity.com/pingone-api/davinci/getting-started-with-davinci/ui-options.html llms_txt: https://developer.pingidentity.com/pingone-api/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md section_ids: pingone-forms: PingOne forms benefits-of-using-forms: Benefits of using forms limitations-with-forms: Limitations with forms custom-html-through-the-http-connector: Custom HTML through the HTTP connector benefits-of-custom-html: Benefits of custom HTML limitations-of-custom-html: Limitations of custom HTML changing-the-user-interface-option: Changing the user interface option --- # DaVinci user interface options There are two options for DaVinci-rendered user interfaces in a flow: * **PingOne Forms** used through the DaVinci Form connector. * **Custom HTML** authored in the **HTML Template** field of an HTTP connector. These are distinct choices that affect authoring, ownership, extensibility, testing, and the work required if the implementation is changed later. The following table summarizes the strengths and weaknesses of each choice. | Decision factor | PingOne Forms | Custom HTML | Analysis | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Fast delivery | Drag-and-drop authoring, templates, and built-in identity controls reduce coding, making this option a strong fit for fast delivery. | Custom HTML requires hands-on design and coding (or agent assistance), unless you already have reusable HTML/SK assets. | Forms generally reduce initial implementation effort. | | Branding and localization | Supported through Forms and PingOne branding themes, which includes translatable keys. | Supported through custom markup, CSS, scripts and language keys, but your organization owns the custom implementation. A good choice if your organization already has an established branding CSS. | Forms centralize a common experience configuration. Custom HTML maximizes control of the user experience. | | Control | Control when using Forms is limited to the component model and its configuration options. | With Custom HTML, you control markup, layout, CSS, and client-side behavior. | For maximizing control, Custom HTML provides more options and capabilities. | | Specialized browser behavior | Uses only the controls and integrations supported by the Forms service. | Offers a broad range of options, including SK-Components, custom HTML, and external scripts or resources. | Custom HTML provides more options when the user interface needs unusual interaction or a specialized browser integration. | | Long-term maintenance | Forms are supported by the PingOne platform. Updates are made in the form builder and related PingOne configuration. | Your team maintains the Custom HTML, SK attributes, CSS, scripts, dependencies, and compatibility behavior. | Custom HTML transfers more lifecycle responsibility to the implementation team. | | Centralized management | Forms form can be reused in multiple flows and can show different content and components dynamically based on the runtime context. | HTML pages are maintained individually within the flow where they appear. HTML Templates can be saved, but they provide a one-time setup shortcut. Nodes do not inherit changes in the template. | Custom HTML transfers more of the management responsibility to the implementation team and might require updates to multiple nodes across multiple flows. | ## PingOne forms The [Forms](../../platform/forms/index.html) service supports the drag-and-drop form builder in the admin console for creating custom forms without writing HTML. You can create interfaces from a blank canvas or use templates for registration, sign-on password reset, and password recovery use cases. You add a form to a DaVinci flow with the [Form Connector](https://docs.pingidentity.com/connectors/form_connector.html). The forms model supports: * Branding and themes. * Localization through translatable keys. * API-based form creation and management. * Predefined controls and behaviors such as inputs, buttons, links, error display, polling, QR code, social login, reCAPTCHA, and MFA/FIDO2-related components. * Built-in validation such as required fields and regular-expression validation, with configured error messages. * Dynamic text and component visibility rules that allow the form to respond to runtime context. ### Benefits of using forms You can create a form in PingOne quickly using drag-and-drop tools and include it in a flow using the Form connector. The collection of templates and themes available in the form builder provide the following advantages: * **Lower initial development cost:** PingOne forms are proven, productized, and tested, eliminating the need to assign an in-house team to design, develop, and test HTML and CSS. * **Faster delivery:** Includes templates and predefined controls that reduce the amount of custom configuration and coding. * **Consistent identity behavior:** Provides standardized validation, error messaging, MFA, reCAPTCHA, and social-login capabilities are exposed as PingOne-supported configured components rather than custom browser code. * **Flexibility:** The Show Form node handles branching automatically. After creating a form, it is easy to add that "saved" form layout to the flow (or other flows) using drag-and-drop tools. * **Centralized experience management:** Provides branding, themes, and translations that is maintained by PingOne. * **Maintenance:** Forms are centrally managed and reused across flows, simplifying updates and maintenance. Your team maintains form configuration in PingOne instead of managing custom markup and runtime scripts. ### Limitations with forms The forms components and their configuration options limit your user interface implementation. A design or interaction that the forms service does not support would require Custom HTML. * **Less direct markup control:** Your team does not control every element of the rendered interface in the same way that it would with a custom template. * **Dependency on Forms behavior:** Future enhancements and upgrades to the interface are dependent on supported component behavior in PingOne and the Form connector. * **Migration:** If the capabilities of Forms do not meet all interface requirements for future development, migration can be challenging, time-consuming, and, in some cases, not possible. ## Custom HTML through the HTTP connector DaVinci supports custom HTML through the **HTML Template** field of the HTTP connector's Custom HTML Template capability. DaVinci recognizes SK attributes in otherwise static HTML and uses them to make the markup function as SK-Components. SK-Components are custom components that provide functionality and UI elements in the **HTML Template** field of connectors such as the HTTP connector. In the editor, SK-Components can appear as badges. When rendered in the widget, they are converted into raw HTML. The following lists some common available elements provided by the out-of-the-box [SK-Components](https://docs.pingidentity.com/davinci/flows/davinci_sk_components.html): * Buttons and identity-provider invocation. * Validation and error messages. * Polling animation to indicate that polling continues. * reCAPTCHA user validation. * File selection and camera capture for supported use cases. * Risk signals and browser fingerprinting. * Third-party iframes and external script loading. | | | | - | --------------------------------------------------------------------------------------------------------- | | | You can assign CSS classes to components and use them with flow-level Custom CSS or an external CSS file. | ### Benefits of custom HTML This user interface option lets you show customized HTML pages, message, flow progress, or send custom responses. You can use the **Custom HTML Template** capability to create complete HTML pages with your own structure, style, and scripts. The following lists the benefits of this interface option: * **Maximum presentation control:** Your team defines the markup, layout, semantics, responsive behavior, and visual hierarchy directly. * **Custom interaction design:** You can implement detailed client-side interaction where the Forms toolbox is insufficient. * **Reuse of web engineering assets:** You can leverage existing HTML and CSS assets, accessibility components, and front-end design-system configurations. * **Specialized integrations:** You can use SK-Components and Custom HTML support for browser behaviors and integrations that are not represented as a standard Forms component. * **Incremental extensibility:** Your design templates can combine ordinary markup with DaVinci-aware SK attributes and components. ### Limitations of custom HTML With the custom HTML option, your team is responsible for HTML structure, SK attributes, CSS, scripts, validation presentation, and browser or device compatibility. While Custom HTML provides greater control and flexibility, it can result in additional management: * **External dependency risk:** Using external scripts, CDN resources, iframes, and third-party integrations can introduce versioning, availability, privacy, performance, and security issues. * **Greater testing scope:** The code that creates your custom behavior must be tested across success, validation, error, cancellation, MFA, localization, responsive, and browser or device paths. * **Contract sensitivity:** Changes such as incorrect or updated IDs, SK attributes, event behavior, or variable names can break the connection between the user interface and the flow. * **Increased development time:** Each non-standard interaction adds design, implementation, accessibility, and testing work to the project. * **HTML and CSS constraints:** The HTML and CSS are contained within a wrapper that you can't control. * **Library constraints:** Use of third-party libraries such as React or Bootstrap are not allowed. ## Changing the user interface option There is no automatic conversion or standard migration if you choose to implement a Forms-to-HTML or HTML-to-Forms conversion. The approaches use different connector types: the Form Connector for Forms and the HTTP connector for custom HTML. If you undertake this change, you are replacing one UI node with another, and you will need to manually reconstruct the relevant configuration. The following table provides general guidance on user interface capabilities that must be verified in the new UI implementation. | Interface component | Acceptance condition | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Data contract | Every value expected by downstream nodes is emitted with the same meaning, required or optional status, and type. | | Events | Submit, next, cancel, retry, back, timeout, and other relevant events produce the intended flow transitions. | | Validation | Client-side and server-side validation, field errors, and form-level errors are visible and actionable. | | Identity controls | Verify MFA, reCAPTCHA, social login, identity-provider, risk, polling, file, and camera behavior where applicable. | | Localization | All supported languages, translatable keys, fallback behavior, and text expansion states are tested. | | Branding and accessibility | Themes, responsive layouts, keyboard navigation, focus management, labels, error announcements, and contrast meet requirements. | | Security and dependencies | External scripts, CDNs, iframes, permissions, privacy implications, and dependency versions have been reviewed. | | Observability | Success and failure outcomes and analytics remain understandable and comparable across the cutover. | | Rollback | The prior UI node and its configuration remain available until the replacement is stable. |