Modern DFFS Admin
Enterprise / Pro add-onModern 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:
| Requirement | Detail |
|---|---|
| Modern DFFS installed | The 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 permission | You 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 license | The 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
DFFSConfigurationListon 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.
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).
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
MyListDEVto SIT suggestsMyListSIT, while a spacedMyList DEVsuggestsMyList SIT. A source with no badge gets a spaced one (Invoices→Invoices 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.
- 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
- 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:

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

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
Miscsettings 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 (ApproverNamevsApprover) 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:

Renaming a field is the richer case:

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]].](https://usercontent.one/wp/spjsworks.com/wp-content/themes/modern-dffs/assets/img/screenshots/admin-07-bulk-update-references.webp?media=1786266236)
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.](https://usercontent.one/wp/spjsworks.com/wp-content/themes/modern-dffs/assets/img/screenshots/admin-08-copy-list-diff.webp?media=1786266236)
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:
- 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.jsand 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. - 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:

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.

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.

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
ModernDFFSEmaillist 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
ModernDFFSEmaillist 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.

