Integration of SharePoint Actions and Forms

Forms and actions normally talk through data: a form saves a change, and the change triggers the automation. Ultimate Forms also supports the direct route. Actions can fire straight from the form, through a Trigger Action button or through form events like form opened and form closed. That unlocks scenarios ordinary events cannot reach, including the classic one this guide builds step by step: counting how many times an item has been viewed.

Two halves of one platform

Ultimate Forms is a complete no-code platform for SharePoint business solutions. Non-technical builders use it to create processes like Help Desk, Vacation Request, and Project Management systems.

Its components divide broadly into two categories.

Front-end components are what users see and touch. Forms and specialized column types handle convenient, error-free data entry. Calendar, Print, and Charts present and output the data.

Back-end components run the business logic behind the scenes. Actions, Alerts, Import, and Item ID are configured by administrators and usually invisible to users. They execute on triggers: item events (added, modified, deleted) and timers (two days before a due date, or every 15 minutes), with manual execution available for most.

Normally the two halves never speak directly. They communicate through data. The form updates an item; the update raises an event; the event runs the action. This indirection is a strength: the same action fires whether the change came from a form, an import, or an integration.

But some scenarios need the direct line.

When the form itself must pull the trigger

Two situations make form-triggered actions the right tool.

The event does not exist. SharePoint raises events for changes, not for looks. There is no "item was viewed" event, yet view logging is a common requirement: audit trails, popularity counters, read confirmations. Only the form knows it was opened. So the form must be the trigger.

Events would drown. A list that undergoes frequent massive automatic updates fires a storm of modification events, and actions attached to them get throttled. Moving the action to the form sidesteps the storm: it runs when a person interacts, not when the machine churns.

Ultimate Forms supports the direct route in two ways. A special button type, Trigger Action, runs the action on click, the user decides when. And form events run actions automatically at moments in the form's life: form opened, form closed, item added, item modified. Buttons are covered in depth in the action buttons guide; this walkthrough uses form events.

The build: a view counter

The goal: increment a number column called Views each time someone opens the item in the Edit or Display form.

Create the action. Make a simple list and add a number column named Views. From the list toolbar, click Design, then Actions. Add an Update list item action that increments the column:

Under Action settings, the formula is simply Views = [Views]+1. The value in square brackets reads the current item, so each run adds one:

Now the step that prevents chaos. Under General settings, uncheck all event types:

This action will be triggered by the form. If it also listened to modification events, its own update would raise a new event, which could run it again. Stripping the events makes the form the single trigger. Remember this habit from the loops walkthrough: an action invoked by something else should own no triggers of its own.

Design the form. Open Form Designer and lay out a form:

Set permissions on the Views column: hidden in the New form, read-only in Edit and Display. Users should see the count, never edit it. The counter's integrity depends on the action being its only writer:

Wire the trigger. Click the Actions button on the form's top toolbar:

Select the action under the Form is opened event. Form is closed works too, with one honest caveat: it will not execute if the user simply closes the browser or navigates away without using the form's buttons. For anything that must be counted reliably, prefer form opened.

Publish and test. Publish the form and create a test item. Open it for display a few times, and watch the Views counter climb:

Allow a few seconds per run; the action executes in the background, not instantaneously. That asynchrony is normal, and worth knowing before you refresh and wonder.

Variation: from counter to audit log

Once the counter works, the audit log is a ten-minute upgrade. The difference is what the action writes.

Add a multiple lines of text column named View Log, hidden from the New form and read-only everywhere else, exactly like Views. Change the action, or add a second one, to append a line to it instead of incrementing a number. The appended line combines the current user and the current time, both available as values in the action's settings.

Attach it to the same Form is opened event. Now every record carries its own readable history: who opened it, and when, line after line. The counter answers "how popular." The log answers "who, exactly," which is the question auditors ask.

Two refinements complete it. Conditions on the action can limit logging to the Display form only, so edits and views are distinguished. And if the log should live outside the item, point a Create list item action at a separate audit list instead, one entry per view, filterable and reportable like any other data.

Nothing in this build required code. A column, a formula, a permission rule, and an event. That is the economy the integration offers: audit capabilities that are usually a product category, assembled from parts you already have.

The pattern behind the demo

The view counter is deliberately small, but the pattern it demonstrates is general: the form's lifecycle is a trigger surface.

Audit trails are the straight extension. Instead of incrementing a number, append to a log: who opened the record and when, which regulated industries ask for routinely. Read confirmation is the same mechanism with a different column: a policy item that stamps "viewed by" when the Display form opens.

Opening-time preparation is the forward direction. An action on form opened can fetch and refresh values before the user works: pulling current data from an external system through a service call, so the form always shows this morning's truth rather than last save's.

And the Trigger Action button covers everything deliberate: run the sync now, recalculate now, log this now, at the user's choice rather than the form's lifecycle. Between buttons and form events, the whole space between "user did something" and "data changed" becomes automatable.

One discipline keeps it healthy. Form-triggered actions bypass the usual event trail, so name them clearly, keep them eventless, and let the action column's execution history remain your audit of what ran. The data-driven route stays the default; the direct line is for the cases that genuinely need it, and now you know how to draw it.