The easiest form interaction is clicking a button. And in Ultimate Forms a single button click can perform many updates at once. It can set a status, append a history log, update the fields that trigger notifications, even prompt the user for notes along the way. Action buttons are how multi-step routines become one-click routines. This guide covers the strategy: which button types exist, when to use each, how a real approval button is configured, and how to make buttons that users understand at a glance.
The guiding question for any form you own: what do users actually do after they open it, and how many of those steps could be one click?
Buttons are a strategy, not a decoration
Forms should let users make updates as easily as possible, and nothing is easier than one click. But the real payoff of button thinking is what it does to multi-step routines. Consider what typically has to happen when a user updates a form in a working process:
- Send an email update to the people who need to know.
- Append a history log in the form, recording that the action took place, by whom, and when.
- Make a status update reflecting the new state.
- Update summary information in the header describing where things now stand.
- Record user notes about the action being committed.
Left to manual editing, that is five fields to find, five chances to forget one, and five slightly different ways each user will do it. The history log gets skipped when someone is rushing, the status and the summary drift apart, and the notification field is updated with the wrong wording so the alert never fires. Consolidated into a button, the same routine is one click that performs all five updates identically every time. The consistency matters as much as the speed: processes run on data that automations and reports read, and buttons are how that data stays uniform.
So audit your busiest form with one question: what are the common updates users make, and can multiple steps consolidate into one click?
Start with the buttons you already have
Every form ships with standard buttons at the bottom, Edit, Save, Cancel, Close, and they belong there, with few exceptions. The overlooked improvement is their text. Changing the default label to match the process, "Save" becoming "Submit Ticket" on a new help desk ticket, costs nothing and removes real confusion: users stop wondering whether Save actually sends the request anywhere. Precise labels are the cheapest UX upgrade a form can get, and a good warm-up for button thinking generally.
Action buttons are the next level: buttons embedded in the form itself that streamline interaction and add functionality. They come in several types, and choosing correctly is most of the design.
The button types, and when each is right
- Action. The workhorses, right for most cases because they match how forms are actually used. One click updates multiple fields in the form. When in doubt, this is the button type to start.
- Trigger Action. Fires actions predefined in your business logic, immediately, rather than waiting for the form to be saved. This is the button for "do something out in SharePoint right now while I keep working": generate the document, create the task, send the data, without leaving the form. (For the broader action machinery behind it, see Integration of SharePoint Actions and Forms.)
- Create Associated Item. Streamlines adding child records to a repeating table by referencing field data from the parent form, so users are not retyping information the form already knows. Adding a line item inherits the context; the user supplies only what is new.
- Print. Loads the item in a print template and generates a document.
- Custom Script. Invokes custom JavaScript, for the rare, special scenario where a developer needs a unique form behavior. If you reach for this often, revisit the other types first; nearly everything belongs in configuration, not code.
With all button types you can even optionally control what happens afterwards with the form. Possibilities include Save and Close, Save and Display, Save and Edit or Save and New.
Anatomy of an approval button
The worked example worth internalizing: a user clicks a button to submit an approval. One click for the user; three updates behind it.
First, the approval field is set to Approved. Second, the History field, a multiline text field, is appended with a line describing the update, building the audit trail nobody has to remember to maintain. Third, an Email Update field is set, which trips the alert rule that notifies the stakeholders.
All of it is configured in the button's settings: pick each field that needs updating and provide the relevant value or text. No workflow, no code, just a mapping from one click to several field changes. And because the history line and the notification text are configured once, every approval in the system reads the same way forever.
Now add the refinement that makes buttons feel intelligent: input parameters. A button can prompt the user for information at click time, so the approve button asks for update notes, and the note the user types flows into the history log and the notification. The user experiences one dialog and one click; the record captures everything. Input parameters are the difference between a button that performs a routine and a button that has a short conversation first, and they remove the last excuse for a separate "notes" editing step.
The same pattern generalizes to whatever verbs your process speaks: Reject with a required reason, Escalate with a priority picker, Complete with a resolution summary. Seven ready-made patterns along these lines are collected in Seven Magic Buttons for SharePoint Forms.
Make them look like what they do
Buttons carry meaning through appearance, and the styling options, icons, colors, and text, are there to be used. A green check-marked Approve next to a red Reject communicates before anyone reads a word; an icon on the Escalate button makes it findable in a busy form. Two habits keep button bars honest: label with verbs that match the process vocabulary ("Submit for Review," not "OK"), and reserve strong colors for the actions that deserve attention. A form whose buttons look consistent across your solutions is also a form nobody needs retraining on; if you maintain many forms, fold button styles into your tenant-wide form standards.
Placement follows function: standard buttons stay at the bottom where users expect them, while action buttons sit near the content they act on. And buttons need not stop at the form: the same one-click philosophy extends to alert emails, where recipients act from the inbox, and to command bars and context menus, where actions run from the list view without opening the form at all. Configuration specifics for buttons in modern forms are covered in Action Buttons in Modern SharePoint Forms.
The best way to discover opportunities is practice: pick the form your team touches most, watch what users do after opening it, and build the button that does it for them. Then look for the next one. Forms limited to the standard buttons make users do the work; forms designed around action buttons do the work themselves.
Frequently asked questions
What is an action button in a SharePoint form? A button embedded in the form that performs configured updates on click: setting fields, appending logs, triggering actions, or creating related items, so multi-step routines become one click.
Can one button update several fields at once? Yes. In the button's settings you pick each field to update and the value or text to apply, and all updates happen together on click, identically every time.
Can a button ask the user for input? Yes. Input parameters prompt the user at click time, for approval notes, a rejection reason, a priority, and the response flows into the configured updates.
What is the difference between Action and Trigger Action buttons? Action buttons update fields in the form (optionally saving, reopening, or opening another form). Trigger Action buttons fire predefined business logic actions (from the Actions component) immediately, without waiting for the form to be saved.
Can I rename the standard Save and Cancel buttons? Yes, and you often should: "Submit Ticket" tells a user exactly what Save will do. Precise labels remove confusion at zero cost.
Can buttons be styled? Yes: text, colors, and icons are all configurable, so an Approve can look approving and a Reject unmistakable. Consistent styling across forms doubles as training.
Add your comment
