Building a custom DNN forms module: A developer walkthrough

DotNetNuke remains a practical platform for organisations that need configurable web applications without building an entire portal from scratch. A custom forms module can support enquiries, applications, registrations, internal requests and repeatable data collection while preserving the permissions, hosting and administration features familiar to DNN users.

This walkthrough follows the development of a custom DNN forms module from requirements to deployment. It covers data modelling, module packaging, dynamic fields, validation, privacy controls and ongoing maintenance, with particular consideration for Australian organisations operating across cities, time zones and regulatory environments.

Define the scope, tenancy and data model

Start with the forms the module must support rather than with its interface. Identify required field types, conditional logic, file attachments, approval stages, notifications and reporting. Separate common engine features from tenant-specific configuration so the same module package can serve several portals without allowing one customer’s form definitions to leak into another.

A useful relational design includes a form definition table, a field definition table, a submission table and a submission value table. Definitions can also use JSON for rapid changes, but normalised tables make reporting, validation and data migration more straightforward. Each record should include creation and modification timestamps, the user responsible for changes and a tenant identifier where multi-tenancy is required.

Time handling deserves early attention. Store event timestamps in UTC, then convert them using the tenant’s configured time zone. Organisations working across Sydney, Melbourne, Brisbane and Perth must account for different UTC offsets and daylight-saving rules. Keeping canonical timestamps in the database prevents duplicated records and inconsistent notifications during clock changes.

Build the module package and administration experience

A DNN extension generally includes a manifest, module controls, supporting assemblies, client assets and installation scripts. Target the .NET version supported by the DNN Platform release installed on the destination site rather than assuming that the newest framework is compatible. Package the module as an installable ZIP and test it through a clean extension installation before introducing upgrade scripts.

The administration screen should let authorised staff create forms, arrange fields, set validation rules and publish revisions. Use the DNN APIs for user identities, roles, localisation and file management instead of duplicating platform capabilities. Where the DNN version provides dependency-injection hooks, register application services through its service registry to keep controllers and business logic testable.

Keep templates, default settings and reusable field definitions separate from actual responses. A published form should have a version number so that existing submissions remain intelligible after fields are renamed or removed. Scheduling can also help with reminder tasks, abandoned-submission processing and recurring reports, but scheduled jobs must be safe to retry and restricted to the appropriate tenant.

Create the public form and submission workflow

DNN modules may host user interfaces through Web Forms, Razor views or a hybrid arrangement, depending on the platform version and existing site conventions. Whichever approach is used, produce responsive layouts that work on the phones and tablets commonly used by people completing forms during travel or between appointments. Clear labels, visible progress and sensible defaults reduce abandonment without hiding important terms.

Apply validation on both sides of the request. Browser validation improves the experience, while server validation remains the authoritative control. Use allow-lists where possible, normalise values before business rules are applied, and return field-level messages that identify the problem without exposing internal details. Protected forms also need anti-forgery tokens, rate limiting and duplicate-submission protection.

The workflow should cover more than a successful save. A typical submission moves from draft to submitted, then through review, acceptance or rejection, with an audit trail for every transition. Send notifications through a background task or retryable queue rather than tying delivery to the web request. For uploaded documents, validate size and type, store files outside executable paths, scan them and use generated names to avoid unsafe user-supplied filenames.

Protect personal information and Australian compliance

If the Australian Privacy Act 1988 and the Australian Privacy Principles apply to the organisation’s activities, the form should explain why information is being collected, who will access it and how it will be handled. Record consent when it is the legal basis relied upon, but do not make every optional field conditional on consent. Provide mechanisms for requesting access and correction, and retain only the data needed for the stated business purpose.

Commercial electronic messages require particular care under the Spam Act 2003. Subscription checkboxes should be unticked by default, consent records should be retained, and unsubscribe mechanisms must work without excessive delay. A separate submission consent should not automatically become permission to send marketing material. These controls belong in the module’s configuration and audit history rather than in hard-coded email templates.

Security also depends on DNN host configuration. Apply least-privilege roles for viewing, editing, exporting and deleting submissions, and ensure that a site administrator cannot bypass records they are not authorised to access. Encrypt sensitive data in transit, protect connection strings outside source control, and avoid storing credentials or unencrypted personal information in module settings. Define retention periods and an approved deletion process, then test that both operate consistently.

Test, deploy and maintain the module

Use a dedicated test portal with representative forms, sample users and realistic data. Automate tests around field validation, permission checks, workflow transitions and tenant isolation. Include boundary cases such as long values, unsupported attachments, duplicate requests and malformed API payloads. A second test installation should confirm that package upgrades work from the currently deployed module version.

Database changes need forward scripts, rollback procedures and backups taken before deployment. Record module, schema and configuration versions so a support team can reproduce an incident. After release, monitor DNN event logs, application logs and submission failure counters without logging confidential form responses. A controlled feedback process lets authorised users report confusing fields while protecting the integrity of submitted records.

Long-term support requires testing against future DNN Platform releases and documenting extension points that depend on platform behaviour. For a requirement workshop or delivery estimate, Aricie’s experience with DotNetNuke solutions, custom software and professional training can be explored through Aricie sales consultation. Its broader portfolio, including Acoléa, Adylic, AricieGrid and Budg-Immos, also demonstrates the value of reusable business applications built around clear workflows and maintainable code.