Purpose
The skill brings focused form-engineering guidance, current Microsoft Learn references, sanitised Lead and Contact form exports, and an experimental visual system into one repository. Its goal is to help an agent make useful form changes while recognising which markup, data attributes, inline widths, validation, and consent settings remain owned by Dynamics.
Current scope
- Recognise and preserve Designer-managed HTML and
data-*attributes. - Understand published layout-width behaviour, including inline section and container widths and flex-basis values.
- Use the standard section, container, column, field, and label spacing patterns found in published form markup.
- Work with script-hosted forms, dynamic rendering, React embedding, lookups, prefill, unmapped fields, and submitted values.
- Add scoped CSS and event-driven JavaScript without relying on inline event handlers.
- Customise validation, submission feedback, redirects, consent controls, fields, and fonts.
- Account for public-form bot protection and service-protection throttling.
- Check changing platform behaviour against current Microsoft Learn documentation.
Included reference material
The repository contains the core SKILL.md instructions, focused references for structure, Designer elements, embedding, custom JavaScript, fonts, security, prefill, submitted values, and submission feedback, plus sanitised default and experimental form variants.
The default Lead and Contact exports are comparison baselines. Experimental branded styling is layered over the Dynamics default form; it does not take ownership of sections, columns, widths, or flex layout.
Why published verification matters
The Dynamics Designer can rewrite HTML, CSS, and inline layout values when a form is saved. Its editing canvas also adds overlays and editor-specific styles that do not represent the published page. A local preview can therefore help find obvious errors but cannot prove that an external embed or published standalone page has the right computed width, responsive behaviour, or submission lifecycle.
Known limitations
- The design system has received limited testing with the included Lead form.
- Contact minimal and branded variants are not yet available.
- Field addition, removal, reordering, and resizing have not been tested across every Designer layout and field type.
- Standalone, embedded, React, and iframe scenarios have not all been verified.
- Keyboard, screen-reader, high-contrast, zoom, mobile, reduced-motion, validation, redirect, and server-error states need broader testing.
- There are not yet automated structural regression tests or end-to-end Dynamics environment tests.
Safe development principles
- Preserve generated metadata, field attributes, IDs, validation, consent configuration, and Designer structures unless a task explicitly requires a change.
- Keep untouched exports as comparison baselines.
- Apply visual overrides after the Dynamics stylesheet and avoid structural layout ownership.
- Verify changing platform behaviour against official Microsoft Learn documentation.
- Test in a non-production form, then inspect both the Designer and published result.
- Remove customer data, environment URLs, form IDs, tracking identifiers, and private assets from shared examples.
Who should use it
The repository is useful for Dynamics 365 developers, Customer Insights specialists, CRM teams, and technical marketers who need a documented starting point for form code. Because it is alpha software, treat it as a reference and testing aid rather than an authoritative production automation.