Loading

Submission Success Actions

Two settings decide what happens at either end of a request. The success action decides what the requester sees the moment they submit. The Process Complete Action decides what happens once the last stage has approved.

Where to find it

Architect Panel → Forms:

  • User Input Views — both settings, when the view is created or through Edit User Input View
  • Process Inspector — the Where it ends panel shows the Process Complete Action

The success action

The success action is chosen from a list when you create the view. The choices, in the order the list offers them:

  1. Show a message: HTML you write replaces the form on the page. Use it to confirm receipt and say what happens next.
  2. Go to a web address: the browser is sent to a URL you enter.
  3. Refresh the page the form sits on.
  4. Refresh the web app, for forms used inside the installed app.
  5. Go to a page in the application, named by its query string rather than a full address.
  6. Run a JavaScript handler: a function your developer has added to the page receives control. Only useful where such a function exists.
  7. A PHP callback option. The submission code does not recognise this choice: the request is saved, and the requester then sees a configuration error. Do not use it.

In the message, the web address and the page query string, %%AM-ID%% is replaced by the new record's ID. So Your reference is BA-%%AM-ID%% shows the prefixed reference, and a URL can carry the ID to a page that displays the request.

The Process Complete Action

This setting is required. It runs when the last stage approves the request; on a view with no stages, it runs on submission. Three choices:

  • Send E-mail: choose who receives it (the same recipient choices a stage offers), the account it is sent from, and optionally a template. Without a template the platform writes the message, with a subject of the view name, your site name and the reference.
  • Run PHP Callback Function: name a function your developer has added to the application's custom code. If the function does not exist the error is logged and nothing else happens.
  • Nothing.

This is separate from the requester's completion e-mail, which is one of the six e-mails under Standard E-mails/Notifications. A request completed by a stage time-out using Complete Request does not run the Process Complete Action and sends nothing.

Setting them up

  1. Decide what the requester needs to know at submission: usually that it arrived, the reference and the next step.
  2. On the builder, choose the success action and fill in its message, address or query string.
  3. Choose the Process Complete Action. If it sends an e-mail, name the sending account.
  4. Save, submit a test request with View Form, and approve it through every stage to see both ends work.

What goes wrong

  • A configuration error after submitting: the success action is set to the PHP callback option, or holds a value the platform does not recognise. The request was saved; change the success action.
  • Nothing visible after submitting: a JavaScript handler was chosen and the page has no such function.
  • No completion e-mail: check whether you meant the Process Complete Action or the requester's completion e-mail. They are different settings.

Worked example

A public contact form (security level 1) uses Show a message: Thank you. Your reference is CF-%%AM-ID%%. We reply within two working days. Its single stage, Triage, e-mails the support mailbox. Its Process Complete Action sends an e-mail to the address in the form's e-mail field from the support account, using a template that thanks the person and links to the knowledge base. The team tests by submitting through View Form and approving at Triage.

Recommendations

  • Show the reference in the success message using %%AM-ID%% and your prefix.
  • Prefer a message over a redirect unless the next page adds something.
  • Avoid the PHP callback success option.
  • Test end to end after any change to either setting.