Forms, in depth

A form has one or more pages. Each page holds fields from a palette. The palette has short and long text, single choice, multiple choice, dropdown, yes or no, rating, date, file upload, rich text, image, waivers, section panels and matrix grids. A condition on a field or a contact box shows it only after a chosen answer. Staff write every title, label, page name and choice in English and in Spanish. A link that ends in a language code opens the form in that language. Where a Spanish label is missing, the form shows the English text.

Staff cannot add an Email or Phone field. The parish already holds those details for a signed-in person, so the builder refuses them. A choice can have its own capacity. A full choice shows "Capacity Reached". A form with limited spots also holds a spot for a visitor for a few minutes.

The form owner chooses the audience.

• Public. Anyone with the link can answer. A visitor who is not signed in gives contact details, and a short anti-spam check can run first.
• Signed in. The form asks for a parish login. It then fills in name, email and phone from the profile, and it can ask which child the answer is for.
• Rule based. The parish can set eligibility rules. A person who does not qualify sees the reason.

Staff can also set a maximum number of answers, an open date and a close date. A form past its close date shows Closed on its own. A staff member can give one person a special link that works after the close.

A restricted form holds private answers. Only global admins and the staff of the owning module read them. Forms staff can still edit, approve and publish the form, but they cannot open its answers or analytics.

A form can require one or more standard waivers. The person must accept each one before the form completes. A form can also charge a fee through an approved payment link, which Stripe processes. The form saves a paid answer after the payment succeeds. A person sees the status of each answer as Submitted, Paid, Pending Payment or Withdrawn. A form cannot publish while its payment link is still waiting for approval.

A new form starts as a draft. The builder submits it for approval. A person with the Forms Approver role, or a global admin, approves it, or rejects it with a reason. The builder reads the reason by email. Approval does not publish. The builder publishes the form. Revert to draft takes a published form down and keeps its approval. A save on a form that was approved sends it back to draft approval, but a published form stays live. Staff can duplicate a form. The copy gets the questions, but not the payment link, short link or any outgoing destination.

Each form has a submissions list. Staff filter it by status, see who paid, and watch the capacity meters. They match an answer to a person in the parish records, either automatically or by hand. They can withdraw an answer, send a new invoice, download uploaded files and export the list. A Capacity tab lists every form that has a limit and turns red at 80 percent. Analytics shows the total number of answers. Completion rate, average time, daily counts and per-question breakdowns are not turned on yet.

Staff set email in Settings. Only the Forms staff set the other three, in Send it elsewhere. Each outside destination receives only completed answers, including paid ones after payment succeeds.

• Email. A new answer can go to a list of addresses. If the list is empty, the form creator gets it. A signed-in person can also receive a copy.
• Excel workbook. Each answer adds one row to a workbook in OneDrive. The row carries the answer ID, the time, name, email, phone and one column per question. Staff can sort and reorder the columns. New questions add new columns. A repeat never adds a second row.
• SharePoint list. Each answer becomes one item in a list on the parish SharePoint site. Staff match each list column to a question, a system value or a fixed value. A preview shows a made-up item. A required column with no source blocks the save. A value that does not fit leaves that column empty.
• Signed webhook. The form sends each answer as JSON to a web address. The address must use HTTPS. If staff set a secret, each request carries an HMAC-SHA256 signature. Headers name the event, the form, the answer and the delivery, so the receiver can drop repeats.

Excel and SharePoint deliveries work only after an admin connects a Microsoft account. They do not copy answers made before staff turned them on. A restricted form cannot send to a webhook or to Excel.

The answer is always safe in the parish database first. A queue then sends it. If a send fails for a reason that may pass, the system tries again. The waits are 1 minute, 5 minutes, 30 minutes, 1 hour and 2 hours. The limit is six tries. A busy or down receiver counts as such a failure. A plain refusal, such as a deleted workbook or revoked access, fails at once. When a delivery fails for good, the Excel path emails the form owner and the webhook path raises an alert for the technical team. Each failed delivery shows on the submissions page with its error. Staff fix the cause and press Retry. A retry never creates a second row or item.