Custom intake forms that fit your workflow

Digital Sanctum scopes and builds mobile-friendly intake journeys around your questions, documents and systems. The agreed solution can include conditional questions, completed or fillable PDF outputs, approved delivery and authenticated mapping to a specific application where a suitable API is available.

We begin with the workflow, not a generic list of fields.

From first question to usable information

Mobile-friendly entry · Conditional questions · PDF mapping · Approved delivery · Specific API integration · Testing and handover

An intake form is more than a list of fields

A form connects someone trying to get something done with the people and systems that act on their information.

When that connection is unclear, people can struggle to answer questions, repeat information or wonder whether anything was submitted. Your team may then need to interpret documents, follow up missing details or re-enter answers elsewhere.

A custom form project brings those decisions together: what to ask, when to ask it, which answers are required and what happens next.

That might mean replacing an awkward document with a guided mobile journey. It might mean preparing a consistent PDF, or mapping agreed fields into an existing application. We establish the practical scope before choosing the implementation.

01 — Start with the real workflow

We map who completes the form, what they need to achieve, who uses the result and which decisions follow submission.

Discovery covers existing questions and documents, necessary information, approval responsibilities and the intended output. We also identify where the current process becomes confusing or requires manual repair.

The result is an agreed journey and a clearer basis for deciding what belongs in the form—and what does not.

02 — Ask relevant questions on a usable mobile form

Questions are organised around the person’s task rather than your internal database structure.

Conditional logic can reveal follow-up questions when they become relevant. A selected Other option, for example, can reveal a request for detail without showing that field to everyone.

The design can include clear labels, practical date entry, suitable keyboard hints, keyboard operation and understandable validation. If an earlier answer changes, dependent information needs explicit handling rather than silent deletion or accidental submission.

03 — Map answers into the document you need

Where a PDF is part of the workflow, we map agreed fields to an approved document structure.

A completed PDF contains the supplied answers. A fillable PDF retains supported fields for further entry. We agree which output is needed, how it should behave and how it will be checked.

The journey also distinguishes generating a document from downloading or sending it. Continue should advance the form—not unexpectedly download a file or imply that information has reached another system.

04 — Deliver through an agreed route

We define what happens after submission: which information goes where, what confirmation is available and who handles exceptions.

Delivery may involve a document or an authenticated connection to a specific application. API work depends on the destination’s available interface, authorised access, supported fields and operating constraints.

Mapping includes validation, authentication, response handling and recovery appropriate to that connection. A successful request acknowledgement is not automatically proof that the entire business process has finished.

05 — Test failures as well as the ordinary path

Testing uses synthetic data to check the agreed journey, including conditional branches, invalid answers, interrupted steps and included document or delivery processes.

We check what people see when something fails, not just when it succeeds. Recovery should report the known state, preserve appropriate input where supported and avoid encouraging duplicate submissions when the result is uncertain.

The test scope and any remaining limitations are documented, rather than turning one successful demonstration into a blanket assurance.

06 — Hand over something your team can maintain

Handover can include workflow notes, field mappings, configuration guidance, test evidence and ownership boundaries.

We identify who approves question changes, document revisions and integration updates. Where ongoing maintenance is required, its responsibilities and scope are agreed separately.

Changes to an external API, a PDF template or your own process can affect the form. Keeping those dependencies visible makes future updates easier to assess.

What the engagement covers—and what it does not assume

A project can cover discovery, form design and build, document mapping, approved delivery, suitable API work, testing and handover. Maintenance can be scoped to match the solution.

We do not assume every PDF can be imported, every application has a usable API or every workflow needs persistent drafts. Save-and-return behaviour, storage, retention and deletion need explicit decisions that match the implementation.

Your organisation remains responsible for approving the purpose of collection, substantive declarations and applicable handling requirements. Accessibility goals and testing are scoped explicitly; this service description is not a certification or a promise of universal compatibility.

Frequently asked questions

Can we start with an existing form or PDF?

Yes. An existing document can help establish the questions, declarations and output requirements. We assess which parts should remain and which need a different interaction. Use a blank or redacted example rather than sending completed personal records with an initial enquiry.

Can the form connect to our current software?

Potentially. We need to confirm the specific application, available API, authorised access and field requirements. If a suitable connection is unavailable, discovery can consider an agreed document-based or other supported workflow instead.

Can people save and return later?

That can be considered where needed. The recovery mechanism, storage, expiry and deletion behaviour must be designed and agreed; it is not assumed as a default feature.

What should we include in an enquiry?

Describe the task, who completes it, the desired output and any application involved. Mention important approval or operational constraints. Do not include passwords, API keys or completed sensitive forms.