Operations
Part of Landing page software operations: gates and rollback
Landing page software operating workflow: brief to archive
This landing page software operating workflow takes a page from approved brief through release and archive, with named tools, evidence and owners.
A workable landing page software operating workflow moves one identified release through controlled states. Each hand-off names the version, evidence received, decision owner and unresolved exception. Publishing is a state change, not proof that the page is lawful, accessible, secure or effective.
This procedure assumes that the page owner operates in England. UK legal and regulator sources may apply, but qualified reviewers must assess the configured page and facts before release.
What to take away
- Publishing is a state change, not proof the page is lawful, accessible, secure or effective.
- Each hand-off must name the version, evidence received, decision owner and unresolved exception.
- Any material edit after approval reopens the affected gate, and mixed versions should be refused.
- Observation owners should be assigned before traffic starts, watching form failures, scripts and complaints.
- Close the record only after downstream systems and the domain route have been checked.
Open the release record
Give the page a stable identifier. Record its proposed URL, domain owner, business purpose, visitor task, traffic sources, offer, form outcome, data destinations and accountable owner. Attach the approved brief and mark it brief-approved. If the purpose or audience is still disputed, stop here.
Use a restricted SharePoint site as the record of truth for the release record, asset register and evidence log, or name the equivalent controlled workspace your organisation uses. Record the workspace location, template and owner in the release record.
For a concrete example, use Unbounce as the landing-page platform, Typeform for the form, Cookiebot for consent management, HubSpot CRM as the submission destination and SharePoint for release records. This is an illustrative stack, not an integration guarantee: verify the chosen plans, connections, data flows, permissions and export options before adopting it.
Release record essentials
- Stable page identifier
- Proposed URL and domain owner
- Business purpose and visitor task
- Traffic sources and offer
- Form outcome and data destinations
- Accountable owner and approved brief
Next, list the people who may edit, approve, publish or administer the domain. The NCSC's UK guidance on using SaaS securely recommends reviewing permissions, applying least privilege and retaining useful activity logs. Grant access by task and remove it when the task ends.
Build an evidence-ready draft
Create the page in a non-production environment with synthetic form records. Number the copy, design, form schema and tag configuration as one release candidate. For each objective claim, record the visible wording, likely interpretation, source, date, limitations and evidence owner. The ASA's CAP Code requires marketers to hold documentary evidence to substantiate objective claims before distribution.
Add an asset register for images, testimonials, templates and typefaces. Keep licence proof and permitted use beside the candidate. A missing right is a release stop, even if the design is finished.
Map the form and tracking
Draw the path of each field and event through the landing-page service and connected systems. In the illustrative stack, verify whether Typeform sends each submission to HubSpot, what copies remain and who can access them; never infer a connection from product names. Record purpose, recipient, retention period, deletion trigger and route, access group, and the proposed controller or processor analysis for every copy.
Use the organisation's approved retention schedule and enter the actual period for each destination before release; if no approved period exists, stop form capture until the accountable privacy owner resolves it. Do not request a field merely because the software offers it.
Inventory tags, pixels, scripts and storage. The ICO's storage and access technologies guidance addresses PECR and UK GDPR questions for these technologies. The privacy and PECR reviewer must record the applicable UK GDPR lawful basis for personal data and whether PECR consent is required for each storage or access technology. A consent-tool preset is not the decision.
Run independent release gates
Send the same candidate version to the required reviewers. Advertising review covers claims and final impression. Rights review checks permitted media use. Privacy and PECR review follows fields, recipients, tracking and withdrawal. Security review checks accounts, integrations, logs and recovery. Accessibility review completes the critical form journey.
The W3C forms tutorial covers labels, instructions, keyboard use and error handling. Record browser, viewport, assistive technology where used, steps and observed result. A scanner result can support this record but cannot replace manual completion of the task.
Material edits include changes to the headline or objective claims, offer or call to action, audience or traffic source, form fields or destination, tags or consent settings, privacy wording, assets, domain or redirects. Reopen each affected gate, issue a new version and checksum, and have the release controller refuse a bundle containing mixed versions. A reviewer may record that a gate is unaffected, but must not assume that it carries over.
Publish, observe and correct
At release, store the approved checksum, publishing account, Europe/London timestamp, live URL and rollback target. Check the final page, form destination, redirects, tracking behaviour and visible qualifications. Preserve screenshots only as evidence of appearance, not as a substitute for source records.
Assign observation owners before traffic starts. Watch form failures, unexpected scripts, complaint routes, access events and supplier notices. Leave intervention thresholds blank until the buyer approves them or cites a signed contract.
If a claim, rights, data, security or accessibility issue appears, classify it and use the pre-agreed safe action. That may mean pausing promotion, disabling a tag, withdrawing the page or restoring a known version. The NCSC's incident management guidance supports preparation, response and recovery, but the actual reporting and legal decisions require specialist review.
Close or archive the page
When the campaign ends, record the final state. Export content, assets, form schema, configuration inventory, approvals and logs; retain permitted form data only under its recorded retention rule. Use available platform exports and portable records such as PDF or CSV where suitable, verify that the archive can be retrieved, remove access and integrations that are no longer needed, and check redirects. The owner signs the close record only after downstream systems and the domain route have been checked.
Before you act
- Give the page a stable identifier and attach the approved brief.
- Grant access by task and remove it when the task ends.
- Record evidence for each objective claim before distribution.
- Map each form field and tracking technology to purpose and recipient.
- Send one candidate version to all required reviewers.
- Store the approved checksum, timestamp, live URL and rollback target.
Common questions
What should happen if the purpose or audience is still disputed?
Do not mark the release brief-approved or proceed to build until the purpose and audience are agreed. Then name the actual page, form, consent and CRM tools in the release record; Unbounce, Typeform, Cookiebot and HubSpot are examples, not a required or guaranteed-connected stack.
Can a scanner result replace manual testing of the form?
No. Test the same candidate version through the configured form route using synthetic records, and check validation, error handling and the actual destination. Record browser, viewport, assistive technology where used, steps and observed result; a scanner supports this evidence but cannot replace manual completion of the critical form journey.
What evidence should be kept at the point of release?
Store the approved checksum, publishing account, Europe/London timestamp, live URL and rollback target. Record the configured form destination, redirects, tracking behaviour and visible qualifications, then retain suitable exports and evidence in the named controlled workspace. Preserve screenshots as evidence of appearance, not as a substitute for source records.
