Outcome and scope
Use Tally to receive a requested change to registered details, while keeping identity verification and the actual customer-record update in the management process. A membership number passed in a URL or hidden field is not proof of identity. This design deliberately avoids allowing an unauthenticated response to overwrite the customer master immediately.
A lookup reference is not a secret credential. Decide which changes are suitable for a public intake form and route higher-risk modifications to a stronger authenticated process.
Prepare the fields and destination
Prepare these fields: Change-request ID, lookup reference, requested field, proposed value, contact route, verification state and applied time. Keep source values separate from a reviewer’s confirmed values, and do not reuse an existing column for a different meaning. Create the first record with practice identifiers in a destination whose read and edit access matches the intended staff roles. Inspect the saved result from that role before using live information.
Control of the proposed new address is different from authority over the old customer record. If no adequate verification route exists, hold the request rather than adding more guessable questions.
Build the workflow in order
Define which fields may be changed and show the relevant proposed-value input. Avoid re-collecting old details that are not needed. Establish the verification procedure separately. A hidden field can carry a convenient lookup reference, but treat that value as editable by the respondent rather than a trusted identity claim.
Save each response as a new pending change request. Match it to the customer record using the defined review process. If the contact address itself is changing, use an appropriate independent verification route, such as an already verified channel under the organization’s procedure. A message only to the new address does not establish control of the original record.
An authorized operator applies the verified change and records before-and-after values, request ID and responsible person under the appropriate access policy. Notify the outcome, then close the request. If several requests concern the same customer, reconcile their order and fields before applying them, rather than letting the last received form win by accident.
Work through a small example
In a practice request for customer C-15, alter the hidden reference to C-16 before submitting. The system must not change C-16 automatically. Verify that both requests require review, that only the authorized one is applied, and that processing it again does not send duplicate change-completion notices.
| State | Check | Action |
|---|---|---|
| Change request received | Lookup reference and proposed value | Save in pending verification |
| URL reference altered | A different hidden-field value | Verify; do not assume identity |
| Verified change | Authorized operator approved | Apply to the customer record |
| Conflicting requests | Several versions for one field | Reconcile application order |
Handle changes during operation
Detect conflicting requests for the same field. Preserve application order and an authorized rollback history, while keeping customer details out of broadly accessible logs and notifications.
Estimate cost and usage
The main operational cost is often verification and safe application, not form collection. Review the intake plan separately from the customer-management system. Do not remove verification by treating hidden fields as trusted credentials. Estimate request volume, review time, update and notification work, and conflicting requests; compare an authenticated customer screen when the workload justifies it.
Investigate failures
If a value reverts after a valid change, inspect delayed older requests and other integrations that may overwrite it. Deleting the public form is not the same as managing previously collected responses. Apply the organization’s retention process to obsolete before-and-after values while preserving the audit information it actually needs.
Review before release
Before release, test a normal record, one missing a required value, a repeated identifier and an edited record. Use change-request id to trace the saved result back to the source. The acceptance condition is: Separate intake, verification and application; a URL value is not an update permission. Record the expected result before testing, compare it with the actual saved state, and resolve unexplained differences before increasing the scope.
Official sources
Pricing, availability and feature limits can change. Check the linked official pages before subscribing.
- Tally: Conditional form logicInformation checked: 2026-10-30
- Tally: Hidden fieldsInformation checked: 2026-10-30
- Tally: File uploadsInformation checked: 2026-10-30
- Tally pricingInformation checked: 2026-10-28
- Tally plans and pricingInformation checked: 2026-10-28
- Tally billing and paymentInformation checked: 2026-10-28
