Architecture & Security Overview

Evaluating a migration from Classic DFFS? Section 12 summarizes exactly what changes. Looking for quick answers to a security questionnaire? Start at Appendix A.

1. Executive summary

Modern DFFS is a no-code / low-code forms customization solution for SharePoint Online. It lets business users and site administrators transform standard SharePoint list forms into rich, dynamic forms — with conditional logic, tabs, validation, calculated values, related-item lookups, and formatted layouts — without writing code and without a separate application server.

From a security and architecture standpoint, the defining characteristics are:

• 100% client-side. Modern DFFS runs entirely inside the user’s browser as a Microsoft SharePoint Framework (SPFx) solution. There is no vendor-operated backend, database, or middleware that stores or processes customer data.
• Data never leaves the customer tenant. All form configuration and all list/form data reside in the customer’s own SharePoint Online lists, governed by Microsoft 365. SPJSWorks has no access to it.
• No standing API permissions. The solution requests zero Microsoft Graph or tenant-level API permissions. It operates strictly as the signed-in user, within that user’s existing SharePoint permissions.
• Inherits Microsoft 365 security & compliance. Authentication, authorization, encryption at rest, data residency, auditing, and compliance certifications are provided by the customer’s existing Microsoft 365 tenant. Modern DFFS adds no parallel identity or data store.
• Minimal, transparent external touchpoints. The only outbound vendor call in normal operation is an anonymous license-validation lookup that transmits no customer or tenant data. Optional AI features are off by default and opt-in, and require no credentials and no additional outbound connection unless an administrator chooses to supply an API key.

This architecture means the customer’s existing Microsoft 365 security controls, DLP policies, Conditional Access, retention, and eDiscovery continue to apply unchanged.

2. Product overview

Modern DFFS replaces or enhances the out-of-the-box New / Display / Edit forms of SharePoint lists and libraries. Typical capabilities include:

• Dynamic rules & conditional logic — show/hide/enable/disable/require fields based on other field values, user/group membership, or form state.
• Tabs, sections, and responsive layouts for large forms.
• Field validation and calculated / formula-driven values.
• Related items (vLookup) — surface and manage items from other lists, including cross-site-collection scenarios.
• Rich text, attachments, PDF export, and print-friendly layouts.
• Custom CSS / JavaScript hooks for advanced scenarios (administrator-controlled).
• AI-assisted form building (optional, opt-in) to help administrators author form configurations.

These are configuration features exposed to authorized form designers; end users simply see the resulting form.

3. Architecture

3.1 Technology stack

3.2 Solution components

The solution package contains the following SPFx components, all of which execute in the browser:

Deployment characteristics (from the solution manifest):

• isDomainIsolated: false — the solution does not require an isolated domain because it makes no privileged API calls.
• requiresCustomScript: false — the form customizer does not require the tenant “custom script” capability to be enabled.
• skipFeatureDeployment: true — supports tenant-wide deployment at the administrator’s discretion; scope is controlled by the customer.
• No webApiPermissionRequests are declared — i.e., the app requests no delegated or application Graph/API permissions that a Global/SharePoint Administrator would need to consent to for data access.

3.3 Where configuration and data live

Modern DFFS is configuration-driven, and all configuration is stored inside the customer’s SharePoint tenant:

• Per-list form configuration is stored in SharePoint list properties / supporting items within the same site/list being customized.
• Optional central configuration (for enterprise-wide settings, shared/reusable content, cross-site related-items brokering, and license storage) is stored in a customer-provisioned SharePoint site (commonly named ModernDFFS_Central) using standard SharePoint lists (e.g., a DFFS_Settings key/value list).
• Form/business data entered by end users is stored in the standard SharePoint list items — exactly as it would be without DFFS. DFFS changes how the form is presented, not where the data lives.

There is no external database and no vendor data store. If the customer removes the solution, the underlying SharePoint list data remains intact and accessible through the standard SharePoint forms.

4. Data flows & external connections

Because the solution is client-side, all “normal” traffic is between the user’s browser and the customer’s own Microsoft 365 tenant. The complete set of external (non-tenant) endpoints is small and enumerated below.

Key points:

• Endpoints #2–#4 are the only non-tenant connections. In a deployment with AI features disabled (the default), the only vendor endpoint reached is the anonymous license lookup (#2), which carries no customer data.
• The license lookup can be observed and, if desired, allow-listed or proxied. It is a plain GET to a public blob path; there is no telemetry, beaconing, or usage reporting embedded in the product.
• All external calls use HTTPS/TLS.

For network security teams: if your environment restricts outbound traffic, the two endpoints relevant to core functionality are .blob.core.windows.net (license) and .sharepointonline.com (Microsoft assets). The AI relay endpoint only needs to be reachable if you choose to enable AI features.

5. Security model

5.1 Authentication

Modern DFFS introduces no authentication mechanism of its own. Users are already authenticated to Microsoft 365 / SharePoint Online through the customer’s existing identity provider (Microsoft Entra ID / Azure AD), including any Conditional Access, MFA, and session controls the customer enforces. DFFS runs within that authenticated browser session.

5.2 Authorization & least privilege

• All SharePoint reads and writes performed by DFFS execute as the signed-in user, through the browser, using that user’s existing permissions. DFFS cannot read or write anything the user could not already access through SharePoint directly.
• The solution requests no elevated privileges and no Graph/API application permissions. There is no service principal with standing access to tenant data.
• There is no privilege escalation path introduced by DFFS: it cannot act on behalf of other users, cannot impersonate, and holds no credentials to the tenant.

5.3 Segregation of duties (who can change forms)

Editing DFFS form configuration requires permission to manage the SharePoint list/site in question (i.e., the same permissions SharePoint requires to change list settings). End users who merely fill in forms cannot alter form configuration. Central/enterprise settings live in a dedicated site that the customer secures with standard SharePoint permissions.

5.4 Custom code (CSS/JavaScript) considerations

Modern DFFS offers optional custom CSS and custom JavaScript hooks so advanced form designers can extend behavior. Security-relevant facts:

• These hooks are authored by the same administrators who can already manage the list, and stored in the customer’s own configuration. They are a convenience for people who already have configuration rights — they do not grant new capabilities beyond what a list owner already has.
• The core form customizer sets requiresCustomScript: false, so deploying DFFS does not require enabling the tenant-wide “custom script” setting.
• Customers who wish to prohibit custom scripting can govern it through their own change-management and by restricting who can configure DFFS.

5.5 Data protection

• In transit: all traffic (to SharePoint and to the enumerated vendor endpoints) is over HTTPS/TLS.
• At rest: all configuration and form data is stored in SharePoint Online and is therefore encrypted at rest by Microsoft 365, under the customer’s tenant encryption and (if configured) customer-managed keys.
• Secrets: Modern DFFS stores no tenant secrets. For the optional BYOK AI feature, any API key the administrator enters is stored client-side, encrypted, and is never persisted by the vendor (see §7).

5.6 Auditing & monitoring

Because all data operations are ordinary SharePoint operations performed as the user, they are captured by the customer’s existing Microsoft 365 audit log, Purview, DLP, alerting, and eDiscovery tooling. DFFS does not bypass or shortcut these controls.

6. Privacy & data handling

• No personal data is transmitted to the vendor during normal operation. The license lookup carries only a license code; it does not include user names, email addresses, tenant identifiers, or form content.
• The vendor is not a data processor of customer form data. All personal or business data captured in forms remains in the customer’s SharePoint lists, under the customer’s control and Data Processing Agreement with Microsoft.
• No analytics/telemetry SDKs are embedded for the purpose of tracking end users.
• For the optional AI feature, the customer (as the party enabling it) controls what is sent and to which AI provider; see §7.

This model keeps the customer’s GDPR/CCPA data-controller responsibilities contained within their existing Microsoft 365 environment and their chosen AI provider (if AI is enabled).

7. Optional AI form-building feature

Modern DFFS includes an optional, administrator-facing AI assistant that helps build form configurations (it is a design-time authoring aid — it is not invoked when ordinary users complete forms).

Security-relevant design:

• Off by default / opt-in. No AI call occurs unless an administrator explicitly enables and uses the feature.
• What is sent: the form’s configuration (structure, rules) that the administrator is editing. Custom JS/CSS/HTML fragments are included only if the administrator toggles those options on. It does not send SharePoint list item data.
• Why a relay exists at all. The AI provider APIs do not permit direct browser-to-API calls — cross-origin requests from a SharePoint page to api.anthropic.com, api.openai.com and the rest are rejected. A same-origin hop is therefore technically unavoidable for any in-browser AI feature. The relay is that hop and nothing more: it is a CORS workaround, not a processing, inspection, or logging step. It was deliberately built as a thin pass-through that keeps no state, and the Enterprise option exists so an organization can own that hop outright.
• Three ways to run it — no credentials are required at all:
• Manual transfer (no API key, no outbound connection): the default. The administrator clicks Copy prompt to clipboard — or Download prompt to AI model for prompts over ~50,000 characters, which the UI flags automatically — pastes or uploads it into whatever AI tool the organization has already approved, then returns the result with Paste AI response or Import AI response. In this mode the product makes no AI-related outbound call whatsoever — not to SPJSWorks, not to any AI provider. Nothing needs to be allow-listed, and the organization’s existing approved-AI policy governs the whole exchange. This is the recommended model for regulated environments.
• Bring-Your-Own-Key (BYOK) — a convenience, not a requirement: the administrator supplies their own AI provider API key. The key is stored encrypted in the browser’s local storage, scoped to that machine and user, and is never stored on vendor infrastructure. Each request is passed with the prompt through a stateless relay hosted at spjsworks.com to the provider the administrator selected. The relay forwards the request, streams the answer back, and stores, logs and retains nothing — not the key, not the prompt, not the response. It holds no credentials of its own; the key is supplied per request by the administrator’s browser.
• Enterprise relay: the customer hosts their own relay endpoint and registers it as an AIRelayPath item in the DFFS_Settings list on their central site, so that credentials and traffic are controlled entirely by the customer. Credentials are held in environment variables on the customer’s relay server and are never exposed to the browser — the relay page deliberately ignores any key posted from DFFS. The relay can front Azure OpenAI (including Managed Identity and private endpoints), Claude, OpenAI, Gemini / Vertex AI, AWS Bedrock, or a self-hosted model; the AI endpoint itself need not be internet-reachable, so air-gapped inference is supported, and any zero-data-retention agreement the customer holds with a provider applies end to end. The relay files and the setup guide are published as a free download, so they can be reviewed before any purchase. When the license is resolved from the central site, the vendor-hosted relay is not used at all — AI traffic goes from the browser to the customer’s own endpoint and never reaches SPJSWorks infrastructure. (The switch is keyed on the license being resolved from the central site, not on the license tier alone.)
• Customers who do not wish to use AI can simply leave it disabled; doing so removes the relay endpoint from the solution’s data flows entirely.

8. Licensing & activation

• Licensing is enforced client-side. A valid license unlocks features/tiers; there is no server-side gatekeeper that must be online for forms to function once the license is resolved and cached for the session.
• License codes can be stored locally (in the customer’s SharePoint) or resolved from the central configuration site, with a fallback to the anonymous Azure Blob lookup described in §4.
• An OEM / offline activation model is available for environments that require licenses to be provisioned without ongoing outbound validation. Discuss with the vendor if your environment restricts outbound traffic.
• No customer or tenant data is exchanged as part of licensing beyond the license code itself.

9. Third-party / open-source components

Modern DFFS is built on well-known, actively maintained open-source libraries, including:

• React 17 and Microsoft Fluent UI / Office UI Fabric (UI rendering)
• PnPjs (@pnp/sp, @pnp/graph, @pnp/core) — Microsoft-community SharePoint data-access library
• CodeMirror (in-product code editor for advanced fields)
• expr-eval (safe expression evaluation for formulas — not eval)
• jQuery, Jodit (rich-text editor), react-to-print (PDF/print)

All third-party libraries are bundled into the SPFx package at build time; there are no runtime downloads of code from third-party CDNs. A full dependency manifest (equivalent to a software bill of materials) can be provided from the solution’s package.json on request, and the vendor can supply updated dependency versions per release.

10. Development, release & vulnerability management

• Release cadence: Modern DFFS is actively maintained with a published changelog (https://spjsworks.com/changelog). Updates are delivered as new .sppkg versions that the customer deploys to their App Catalog on their own schedule — the customer controls exactly when an update is applied.
• Build toolchain: current builds use Microsoft’s supported SPFx Heft toolchain on SPFx 1.22.1, tracking Microsoft’s supported framework versions.
• Vulnerability handling: dependency updates and fixes are shipped through the normal release channel. Security concerns can be reported directly to the vendor (see §13); because the solution is client-side and holds no customer data, the blast radius of any issue is bounded by the SharePoint permissions of the signed-in user.
• Change control on the customer side: because deployment is a customer-initiated App Catalog action, customers can pin a version, test in a non-production site/app catalog, and promote through their own environments (DEV/UAT/PROD promotion workflows are supported).

11. Shared responsibility model

12. Migration from Classic DFFS — what changes

The migration keeps the same core principle — your data stays in your SharePoint — while moving onto Microsoft’s supported, governed modern extensibility surface (SPFx), which is generally viewed favorably by enterprise IT because deployment is centralized through the App Catalog and does not depend on the legacy “custom script” capability.

13. Vendor & support information

Note on formal certifications: Modern DFFS is a client-side add-in that stores no customer data outside the customer’s own Microsoft 365 tenant; it therefore inherits the compliance posture of the customer’s Microsoft 365 environment (e.g., Microsoft’s SOC 2 / ISO 27001 / data-residency commitments for SharePoint Online). SPJSWorks is a specialist software vendor rather than a hosting provider, and does not operate a data center or process customer data on its own infrastructure. For questions about vendor-specific attestations, secure-development practices, penetration-test results, a signed security questionnaire, or a formal data-processing addendum, please contact the vendor directly — these can be addressed as part of your procurement process.

Appendix A — Quick answers to common security-questionnaire items

• Does the vendor host or store our data? No. All data stays in the customer’s SharePoint Online tenant.
• Does the app require admin consent to Graph/API permissions? No. No API permissions are requested.
• Does it require enabling SharePoint “custom script”? No (for the form customizer).
• Is data encrypted in transit and at rest? Yes — TLS in transit; Microsoft 365 encryption at rest.
• What outbound connections exist? An anonymous license lookup (no customer data), Microsoft CDN assets, and — only if enabled — an AI relay.
• Can we control update timing? Yes. Updates are customer-deployed via the App Catalog.
• What happens to our data if we remove DFFS? SharePoint list data remains fully intact and accessible via the default forms.
• Is there any telemetry/tracking of end users? No.