← Documentation

Modern DFFS Admin

Enterprise / Pro add-on
Modern DFFS Admin1.0.1.0Released 20 August 2026

Modern DFFS Admin is an administration tool for Modern DFFS (Dynamic Forms for SharePoint). It lets you inventory, back up, promote, copy, activate, and bulk-edit your Modern DFFS form configurations across the sites in your tenant, and generate the Power Automate flows that send DFFS emails — all from a single SharePoint web part.

Where Modern DFFS itself is used to build a form on a single list, the Admin tool is the layer above it: it manages those configurations at scale, moves them safely between environments, and gives you a tenant-wide picture of where DFFS is in use.

Requirements

Before you can use the Admin tool, three things must be true:

RequirementDetail
Modern DFFS installedThe tool works against the DFFS configuration list (DFFSConfigurationList) that Modern DFFS creates on a site. If DFFS isn’t installed on a site, the tool reports it and there’s nothing to manage.
Manage Lists permissionYou need the Manage Lists permission (part of Full Control) on every site you want to inspect or change. The tool checks this per-site and blocks actions where you don’t have it.
A qualifying licenseThe Admin tool shares its license with Modern DFFS. It’s unlocked by the Enterprise tier, or the Professional tier with the Admin add-on. During the 30-day Modern DFFS trial the tool is fully unlocked.

The Admin tool only ever reads your license — it never edits it. Licenses are administered in the main Modern DFFS solution.

Working with other sites

Most tabs let you choose between the current site (where the web part is hosted) and another site in your tenant. When you point the tool at another site, it re-checks your permissions and the DFFS installation there before doing anything. This is what makes cross-site backup, promotion, and copying possible.

When you pick another site, use Load sites to fetch the sites you can access. The list comes from the SharePoint search index and is security-trimmed — it only ever shows sites you have access to. Once the list is long, a filter box appears above the dropdown so you can find a site by name or URL. In very large tenants search may not return every site, so a site can occasionally be missing from the list even though it exists; the picker notes this beneath the dropdown.

Key concepts

A few ideas run through the whole tool:

  • A DFFS configuration is stored as list items in the hidden DFFSConfigurationList on a site. Each list you’ve built a form for has up to three configuration items — one each for the New, Display (disp), and Edit forms.
  • Snapshots are automatic backups. Whenever the tool overwrites a configuration (during a promote, restore, or bulk update), it first saves the current version to the DFFS snapshot list. Nothing is overwritten without a recoverable copy being kept first.
  • Environments and the promotion chain. DFFS configurations can carry a mapping that defines a DEV → SIT → UAT → PRD path. Environments can live on separate sites, or share one site and differ only by list name (e.g. InvoicesDEV / InvoicesSIT / InvoicesUAT, with no suffix on PRD). The Promote tab uses this mapping to move a config forward one hop at a time.
  • Activation vs. configuration. Activating DFFS on a list routes its forms to the DFFS form customizer. Configuring it (building the actual form) is done in the DFFS config editor. These are separate steps — the Admin tool handles activation and configuration management, not form design.

Features

The web part is organized into tabs. Each tab is a self-contained tool.

1. Browse configs

Browse, back up, and download the Modern DFFS configurations on a site, grouped by the list they belong to.

  • Inventory — See every configuration on the current or another site, grouped by list, with each form (New / Display / Edit) and its last-modified date and editor.
  • Download — Export any single configuration as a JSON file, or use Download all to get every configuration on the site in one JSON file. This is your portable, off-SharePoint backup.
  • Snapshot history — Each list shows its own backup history. Snapshots (taken automatically before every overwrite) are listed newest-first per form, with any backup note attached.
  • Restore — Roll a configuration back to an earlier snapshot. The current active config is snapshotted first, then overwritten with the chosen version, so a restore is itself reversible.
The Browse configs tab: 3 configurations across 1 list with 2 snapshots, grouped under "Purchase / Order Request". The new form config is expanded to show its two snapshots, each labeled "AI restore point" with a date, and each row carries Download and Restore buttons. Collapse all and Download all sit above the list.

2. Activate DFFS

Turn Modern DFFS on or off as the form solution for one or more lists and libraries, on the current or another site. Removing DFFS from a whole site or tenant is covered end to end in turning DFFS off & uninstalling.

  • Select any number of lists/libraries and choose which forms — New, Display, Edit — to activate. The Activate selected and Deactivate selected buttons sit above the table, so they stay in view no matter how long the list is.
  • Activation is additive: it only turns forms on and never silently turns an active form off. To turn DFFS off, use Deactivate selected, which restores the default SharePoint forms.
  • Per-content-type control — Expand a list to include or exclude individual content types. Sealed content types are shown but can’t be changed. Document libraries have no New form, so it’s skipped there automatically.
  • Status at a glance — Colored badges show whether each form is fully on, on for some content types (partial), or off, and preview what an Activate action will change before you apply it.
  • Every action is confirmed before it runs, and results are summarized (activated / deactivated / unchanged / skipped / failed).
The Activate DFFS tab: New, Display and Edit checkboxes for the forms to activate, a status legend reading installed / will activate on Apply / some content types / not installed, and a table of the site's lists and libraries. Each row shows its DFFS status per form — green ticks where DFFS is installed, dashes where it is not — and a content-types column showing how many are included or sealed.

3. Promote config

Move a tested DFFS configuration along its DEV → SIT → UAT → PRD chain — or to a manually chosen target — with safety checks along the way.

  • Pick a source site and the list/config you want to promote. A colored banner shows which environment the config currently lives in and its full promotion path.
  • Choose the next hop from the configured environments (or pick a destination site manually if no path is set). The target list is resolved from each environment’s configured URL and list name.
  • Field-compatibility gate — Before promotion, the tool compares the source and target lists. Promotion is blocked until the target has matching fields, and it offers one-click remediation:
    • Create list — if the target list doesn’t exist yet, create it with all standard fields. You get a Display title box, prefilled with a suggestion and editable before you create. The suggestion carries the destination’s environment badge, replacing any badge already on the source name and keeping its style — promoting MyListDEV to SIT suggests MyListSIT, while a spaced MyList DEV suggests MyList SIT. A source with no badge gets a spaced one (InvoicesInvoices UAT), and PRD drops the badge entirely by convention. The list’s URL name is not editable here — it comes from the promotion mapping, which is what lets the chain resolve the list on the next hop.
    • Add missing fields — add just the fields the config needs.
    • Update choices to match source — align choice-field options when they differ.
    • Type mismatches and extra destination fields are surfaced as warnings.
  • Safe overwrite — All three form items are promoted together, keyed to the target list’s own identity. The destination’s existing config is snapshotted before it’s overwritten, and the promotion mapping is carried over so the chain is preserved.

In practice the gate is what you notice first. Promoting a config whose target list doesn’t exist yet stops before anything is written, and offers to create it:

The Promote config tab: a Source site picker set to mDFFSv2, a "List / config to promote" dropdown showing PurchaseOrderRequestDEV (1 form item), and a blue banner reading "This config lives in DEV · Path: DEV → SIT → UAT → PRD". Under Destination, SIT, UAT and PRD environment buttons with UAT selected, an information line naming the resolved target list PurchaseOrderRequestUAT and its site, and a red warning that the target list does not exist on the destination and must be created before promoting. Below that, a "Display title for the new list" box prefilled with PurchaseOrderRequestUAT, a hint explaining that the title is suggested from the source list and target environment while the URL name comes from the promotion mapping — and to change it in the DFFS configuration's mapping setup if it's wrong — followed by a Create list button.

Once the destination matches, the gate turns green and the promotion reports exactly what it did:

The same Destination section after the target list exists: SIT, UAT and PRD environment buttons with UAT selected, an information line naming the target list PurchaseOrderRequestUAT and noting the source list was PurchaseOrderRequestDEV, a green bar reading "Destination fields match the source. Ready to promote.", a Promote to UAT button, and below it a green result message reading "Promoted 1 form item(s) to 'PurchaseOrderRequestUAT' on UAT — 1 added, 0 updated, 0 unchanged."

4. Bulk update

Change many configurations at once, with a full preview before anything is written. Three modes:

  • Misc setting — Set/merge or delete a key in a config’s Misc settings object. Supports dotted keys for nested values (e.g. promotion.uat); intermediate objects are created as needed. Values are parsed as JSON when valid, otherwise stored as text.
  • Search & replace — Find-and-replace across configuration columns. JSON columns (FormJSON / RulesJSON / Misc) are replaced structurally — only string values are touched, so the JSON stays valid and keys aren’t hit by accident. CustomJS / CustomCSS are raw-text replaced. Supports regex, whole-word, and case-sensitivity options.
  • Replace a field (by internal name) — Rename a field everywhere it’s referenced across configurations: form properties, rule triggers (including person triggers like field:Approver#Email), field-list actions, the target of a Set field value or Compute field value action, and [[..]] / [..] tokens. Tokens are matched with any property accessor, so [[fieldValue:Approver.email]], [[fieldValue:Requester.title]] and [[Lookup.LookupValue]] are all covered. A field whose name merely starts with the one you typed (ApproverName vs Approver) is never touched. Optionally also replace whole-word matches in CustomJS, where you can review and skip individual matches (since code can contain false positives).

Every change is previewed first. You see exactly which configs matched and what would change, and each item is snapshotted before it’s overwritten. You can scope any operation to specific forms and/or a Title fragment.

Pick the changes to apply. Every previewed change has an Apply checkbox and is ticked by default; untick any you want to leave alone (the header checkbox toggles all of them at once). Unticked rows are dimmed, excluded from the apply count, and never written. Changes that can’t be applied — invalid JSON, for example — are listed with their error and have no checkbox.

A Misc setting preview is the simplest case — each row names the key and shows its current value moving to the new one, with (unset) where the config didn’t have the key at all:

The Bulk update tab in Misc setting mode: the Misc key box reads showFieldTypeIcon with Set / merge chosen and a Value of false. The preview reports "6 config(s) matched · 3 change(s) across 3 item(s) · 3 unticked" and lists six rows, each with an Apply checkbox — the three for PurchaseOrderRequest_100 ticked, the three for the DEV, UAT and SIT copies unticked. Each change reads Misc.showFieldTypeIcon followed by its transition, one showing true to false and the rest (unset) to false.

Renaming a field is the richer case:

The Bulk update tab running a field rename: the Bulk update tab is selected, Target configs is left unscoped (all forms, no Title filter), the "Replace a field in configurations (by internal name)" operation is chosen, and the Old / New internal name boxes read Approver and ApprovedBy. Below, a preview reports "5 config(s) matched · 4 change(s) across 3 item(s) · 4 unticked" and lists eight changes, each with an Apply checkbox — the four for PurchaseOrderRequest_100 ticked, the four for the DEV and UAT copies unticked. The changes name their column and count: FormJSON: 1 reference(s) renamed, RulesJSON: 2 reference(s) renamed.

See every reference before you apply it. A field rename also lists each reference individually — where it sits in the configuration, what kind it is (field property, field list entry, rule trigger, or token), and the change itself. Tokens are shown in context, with the surrounding text either side, so you can see the label, email body, or formula the token lives in. Unlike CustomJS matches, these references can’t be skipped one at a time — a configuration that still points at a field it no longer has is broken — so to leave a column alone, untick the whole change.

A "Renamed references" panel listing every reference the rename will rewrite, one collapsible row per config, form and column. One row is expanded to show two references in context: a rule trigger at condition › children[0] › trigger changing from field:Approver#Email to field:ApprovedBy#Email, and a token at actionYes › sendEmail[0] › to changing from [[fieldValue:Approver.email]] to [[fieldValue:ApprovedBy.email]].

5. Copy list

Replicate a list’s field schema onto another list — on a different site, or on the same site under a different URL name. (This copies fields only — to copy a list’s DFFS configuration, use Promote config.)

  • Copy whole list — Recreate a source list, with its standard fields, as a new list. Lookup and managed-metadata fields are skipped. Per-language field names are carried over.
  • Choose the URL name — The URL name field is prefilled with the source list’s own URL name, but you can change it to create the copy at a different address (useful when the destination already has a list at that URL). Invalid characters are flagged as you type. The display title always comes from the source list.
  • Diff & add missing fields — Compare an existing destination list against a source, then add only the fields it’s missing and/or update choice-field options to match. Useful for keeping parallel lists in sync.

In Diff & add missing fields mode, Compare reports what actually differs before you change anything — including choice fields, where it names the field and lists the options on each side:

The end of the Copy list tab in diff mode: a Destination list dropdown set to PurchaseOrderRequestSIT, a Compare button, and the comparison result — "1 choice field(s) differ between source and destination", with a Status line reading source [Pending, Approved, Rejected] versus destination [Pending, Approved] — followed by an "Update choices to match source" button.

6. Remote import

Mirror a list from a site the tool cannot reach directly — an on-prem farm, or a site in another tenant — and bring its Classic DFFS configuration along for conversion.

Everywhere else, the tool reaches other sites with your signed-in token. That doesn’t extend across a tenant boundary or to an on-prem farm, so this tab works in two steps with a small helper script that runs on the source site, where you’re already signed in:

  1. On the source site, install the helper script. The tab has a Setup instructions button that opens step-by-step guidance, plus Download dffs-remote-helper.js and Copy script source — you don’t need to go looking for the file. Put it in a Content Editor, Script Editor, or ModernCEWP web part, then pick a list, optionally tick Include Classic DFFS configuration, choose which of its configurations to include, and copy or download the JSON it produces.
  2. In this tab, paste or upload that JSON, choose a destination site, and either create the list or diff & add missing fields to an existing one — the same two modes as Copy list.

This is the helper, running on the source site:

The Modern DFFS Remote export helper running on a source site: a Site (web) URL box with a Reload lists button, a "List to export" dropdown showing DFFS_Demo, and an "Include Classic DFFS configuration" checkbox. Beneath it a panel lists the three configurations found for that list — Display, Edit and New form, each with its blob size and last-modified date — noting that 351 configurations belonging to other lists are hidden. A Build export button follows, then a summary reading "98 field(s), 3 Classic DFFS config item(s) — 114 KB", Copy to clipboard and Download .json buttons, and the generated JSON.

When Include Classic DFFS configuration is ticked, the helper lists the configurations it found for the list you picked — one per form, with each one’s size and last-modified date — and you can untick any you don’t want. Classic DFFS keeps every configuration in a single list, so by default the helper hides the ones belonging to other lists; Show configurations for other lists reveals them if you need something that isn’t matched to your list. Build export then reports the field count, the number of configurations and the payload size before you copy or download it.

The Remote import tab after reading an export: step 1 offers Setup instructions, Download dffs-remote-helper.js and Copy script source buttons; step 2 shows the pasted export JSON in a text area with Read export and Load from file buttons. A green result banner reports the list name, its source site, and that 98 fields were exported of which 13 are copyable, along with 3 Classic DFFS config items.

Back in the Admin tool, the result banner reports what the helper found — the field count, how many of those are copyable, and how many Classic DFFS configurations came along. The gap between the two field numbers is SharePoint’s own system columns plus the field types listed below, so a list will always report far more fields than it copies.

When the export carried Classic DFFS configurations, they appear at the bottom of the tab, labeled by form (New / Display / Edit). Classic DFFS stores each configuration in a multi-line text column named blob, which is preselected — click Copy configuration, then open the newly created list’s DFFS settings and paste it into Modern DFFS’s import function, which performs the classic-to-modern conversion.

Copy whole item as JSON, beside it, copies the entire exported list item instead — Title, AuthorId, the blob itself, and the rest of the item’s metadata. That’s more than the import needs, so reach for Copy configuration when you’re converting. It’s useful as a record of where a configuration came from: who created and last edited it, when, and the complete original config alongside.

Configurations deleted in Classic DFFS are kept in its list with a [deleted] marker on the Title. The helper lists them, labeled (deleted), but never ticks them for you, and the tab warns before you copy one.

The helper shows its build date, and every export records it. If the helper behaves unexpectedly, check that build against the copy in this tab — a script file left in Site Assets from an earlier install, or one the browser is serving from cache, is the usual cause.

The Destination section of the Remote import tab: options to create the list or diff and add missing fields to an existing one, a destination site picker with a filter box, and a Create list button. Below it a dismissible tip notes that the export carried 3 Classic DFFS configurations waiting at the bottom of the tab. The Classic DFFS configuration section follows, with a Configuration item dropdown showing a Display form dated 2016, a Column dropdown preselecting the blob column, Copy configuration and Copy whole item as JSON buttons, and a preview of the raw classic configuration JSON.

Field selection matches Copy list — lookup, managed-metadata, and calculated fields are skipped. Two things differ: per-language field names are not carried across (reading them needs a site the tool can reach directly, and they don’t exist on SharePoint 2013), and no list data is copied. The source site needs custom script enabled.

7. Email flow

Generate the Power Automate flows that actually send Modern DFFS emails. When a form rule is set to send email via Power Automate, DFFS doesn’t send the message itself — it writes it to a ModernDFFSEmail list on the site, and these flows pick those items up and deliver them.

  • Choose the target site — the current site or another site — then click Prepare email list. The tool ensures the ModernDFFSEmail list exists (creating it if needed) and resolves its GUID.
  • Download the flow packages — two ready-to-import legacy package (.zip) files are generated with the site URL and list GUID already baked in. You need both for full coverage:
    • Send now — triggers on each new item and immediately sends emails that have no send date, then deletes the item.
    • Send later — runs every hour and sends emails whose send date/time (UTC) falls within the current hour, then deletes the item.
  • Import into Power Automate — at make.powerautomate.com, choose My flows → Import → Import Package (Legacy), upload each .zip, and select (or create) a SharePoint connection and an Office 365 Outlook connection to import with. Then open each imported flow and make sure it’s turned on.

Emails are sent from the account that owns the Office 365 Outlook connection. The flows read from — and delete processed items in — the ModernDFFSEmail list on the selected site, so if you send email from several sites, generate and import a set of flows for each site. A Power Automate plan and permission to create flows are required (premium connectors are not needed).

For the full picture — the ModernDFFSEmail column reference, and how to build the two flows by hand instead — see the Send email — Power Automate flow setup guide.

8. Tenant report

Get a tenant-wide picture of where Modern DFFS is installed.

  • Reports which sites have Modern DFFS and how many lists each has it configured on.
  • Expand any site to see the individual lists and open the site directly.
  • Download the full report as JSON.

Coverage is security-trimmed — you only see sites you can access — and depends on the search index. Run it as a tenant or SharePoint administrator for the widest coverage.

9. About

A reference tab showing the product version and build, developer and company, your current license status and tier, the signed-in environment, and the names of the DFFS config and snapshot lists. It also has Show dismissed tips again — see below.

Tips

Some tabs show a one-time hint when it becomes relevant — for example, Remote import points out that an export’s Classic DFFS configurations are waiting at the bottom of the tab.

Dismissing a hint with its × hides it permanently, remembered per browser, so it won’t nag you again. Colleagues on the same site still see it once. To bring them all back, use Show dismissed tips again on the About tab.

Safety model

The tool is built so that destructive actions are always recoverable:

  • Nothing is overwritten without a snapshot. Promote, restore, and bulk update all snapshot the current version first.
  • Every write is confirmed. Bulk changes and promotions show a preview and a confirmation dialog before they run.
  • Permissions are checked per site. You can’t change a site you don’t have Manage Lists on.
  • Promotion is gated. A config won’t promote onto a list whose fields don’t match — you’re guided to fix the target first.

Support

Modern DFFS Admin is developed by Alexander Bautz at SPJSWorks. Questions or problems? Get in touch.