Perform Script on Server, commonly abbreviated PSoS or PSOS, is a FileMaker script step that asks the server hosting a custom app to execute another FileMaker script.
Instead of running the requested script on the user’s computer or mobile device, FileMaker creates a separate session in the FileMaker Server Script Engine.
PSoS can improve the performance of data-intensive operations, move long-running tasks away from the client, and provide a foundation for background processing and parallel execution.
It was introduced with FileMaker 13 and has since become one of the most important tools for building scalable FileMaker applications.
How does PSoS work?
A script running in a compatible FileMaker client calls the Perform Script on Server script step and specifies:
- The script to execute
- An optional script parameter
- Whether the caller should wait for completion
FileMaker Server then creates a new FileMaker Script Engine session and runs the requested script.
The server-side script can return a result using the Exit Script script step. If the caller has selected Wait for completion, it can retrieve that value using Get ( ScriptResult ).
PSoS is supported when called from environments including:
- FileMaker Pro
- FileMaker Go
- FileMaker WebDirect
- Custom Web Publishing
- FileMaker Data API
- FileMaker Server
- FileMaker Cloud
The important point is that the script called by PSoS always runs in a new server-side FMSE session, regardless of where the calling script originated.
Why perform a script on the server?
Processing data close to the database
When a script processes many hosted records from FileMaker Pro or FileMaker Go, data may need to travel repeatedly between the server and the client.
PSoS allows the processing to take place on the same server that hosts the database. This can reduce network traffic and considerably improve performance for some operations.
Typical examples include:
- Updating a large group of records
- Importing or exporting data
- Creating reports or documents
- Processing a queue of transactions
- Communicating with an external API
- Synchronizing data with another system
- Performing complex calculations
- Preparing data for a client
The performance improvement depends on the design of the script and application. Moving an inefficient script to the server does not automatically make it efficient.
Delegating work from a slower client
A mobile device or remote computer may have limited resources or a slow network connection. PSoS allows the client to send a relatively small request to FileMaker Server and let the server perform the substantial work.
This is particularly useful for FileMaker Go and WebDirect applications.
Running processes in the background
When Wait for completion is turned off, the calling script can continue as soon as FileMaker Server has accepted the PSoS request.
The server-side script then continues independently in its own FMSE session. This can be used to start background processing without forcing the user to wait for the complete operation.
However, turning off Wait for completion also means that the caller does not directly receive the final script result. The application must provide another way to track the operation, such as a job record containing its status, result, and error information.
Wait for completion
The Wait for completion option determines the relationship between the calling script and the server-side script.
Wait for completion enabled
The calling script pauses until the PSoS script finishes.
This allows it to retrieve:
- The script result
- The error returned when starting or executing the request
- Confirmation that the server-side operation has completed
This mode is suitable when the client needs the result before proceeding.
Its disadvantage is that the user may have to wait, particularly if the server script is long or queued behind other operations.
Wait for completion disabled
The calling script continues after the request has been transferred to FileMaker Server.
The server-side script runs independently in another session. This is useful for tasks that do not need to finish before the user continues.
This mode should not be confused with a guaranteed job-processing system. If the application needs to know whether the task was completed, the server-side script should record its own status and errors.
PSoS creates a new FileMaker session
A PSoS script does not continue inside the caller’s existing FileMaker session.
The new FMSE session does not automatically inherit the caller’s:
- Current layout
- Current record
- Found set
- Sort order
- Open windows
- Local or global variables
- Global field values
The server-side script must establish its own context.
Developers commonly pass the required information through the PSoS script parameter. This may include a record ID, layout name, requested operation, user information, or a JSON object containing several values.
The server-side script can then navigate to an appropriate layout, find the required records, perform the operation, and return a structured result.
Authentication and privileges
A script started with PSoS uses the same FileMaker account as the calling session.
The server-side script is therefore subject to that account’s privileges unless the script has been explicitly configured to run with full access privileges.
This is an important security characteristic. PSoS is not automatically a way to bypass the privileges of the current user.
Developers should verify that users can call only appropriate scripts and that those scripts validate their parameters before modifying data or performing privileged operations.
PSoS from another server-side script
Originally, Perform Script on Server could be called by FileMaker clients, but not by a script that was already running in the FileMaker Script Engine.
This changed with FileMaker Server 2024, version 21.1.1, released in November 2024.
A server-side script can now use PSoS to launch another script in a separate FMSE session. The calling server-side script can either wait for the new script to complete or allow it to continue in its own thread.
This opened several important architectural possibilities.
Delegating work
A scheduled script can identify a task and transfer it to a separate FMSE session, allowing the original schedule to continue or finish.
Parallel processing
A controller script can divide a large workload into smaller groups and start several worker scripts through PSoS.
For example, a batch of documents could be divided between several independent FMSE sessions rather than being generated sequentially by a single script.
OData background processing
Scripts called through OData already run in FMSE. Before FileMaker Server 2024, such a script could not call PSoS because it was itself a server-side script.
It can now validate an OData request, create a job record, delegate the substantial work to another PSoS session, and return a response without waiting for the complete operation.
Separating controller and worker scripts
A server-side controller can manage a queue while separate worker scripts process individual jobs. This can make complex automation easier to scale and monitor.
Parallel processing requires caution
The ability to start PSoS from FMSE makes parallel execution possible, but it also makes it easier to overload FileMaker Server.
A script that repeatedly starts more PSoS sessions can consume significant CPU, memory, disk, and database resources. It may also create record-locking conflicts or overwhelm an external service with simultaneous requests.
FileMaker Server 2026 adds support for multiple SASE processes, allowing more FMSE workloads to run concurrently. This can improve throughput, but it does not remove the need to control concurrency.
A robust parallel-processing architecture should define:
- The maximum number of workers
- How jobs are assigned
- How duplicate processing is prevented
- How record locks are handled
- How failures are recorded and retried
- How the controller determines that all workers have finished
- How server load is monitored
PSoS should not be used as an unlimited spawning mechanism.
Perform Script and Perform Script on Server
The two script steps serve different purposes.
Perform Script calls another script within the current FileMaker session. The subscript shares the session’s context, including its windows, layouts, found sets, and variables according to the usual FileMaker scoping rules.
Perform Script on Server creates a separate FMSE session. The new script receives only the information explicitly passed to it and establishes its own context.
Using Perform Script is appropriate when the work logically belongs to the current session. PSoS is appropriate when the work should be delegated to FileMaker Server or isolated in a separate process.
PSoS and scheduled scripts
Both PSoS scripts and FileMaker Server schedules are executed by FMSE, but they are started differently.
A schedule starts automatically according to a configuration stored in FileMaker Server. It uses the FileMaker account specified by the administrator.
PSoS is started dynamically by another FileMaker script and uses the account of the calling session.
Schedules are well suited to recurring tasks. PSoS is better suited to work initiated by a user, API request, application event, or another server-side process.
PSoS with Callback
Perform Script on Server with Callback is a separate script step that runs a script on the server without pausing the client. When the server-side script finishes, FileMaker runs a specified callback script in the original client.
This is useful for asynchronous user interfaces. A user can continue working while the server processes a task, then receive the result when it is ready.
Unlike the standard PSoS script step, PSoS with Callback must be started from a supported client such as FileMaker Pro, FileMaker Go, or WebDirect. It cannot itself be used from a FileMaker Server script, the Data API, or Custom Web Publishing.
The callback also runs later in a client context that may have changed. It should therefore receive enough information to identify the relevant window, layout, record, or job.
Designing reliable PSoS scripts
A professional PSoS implementation should consider:
- Server-compatible script steps
- Explicit context initialization
- Structured script parameters
- Structured script results
- Authentication and privileges
- Error capture and logging
- Record commits and record locking
- File access restrictions
- Timeouts and queued FMSE sessions
- Whether the caller waits for completion
- Server capacity and concurrent workloads
For important operations, passing a record ID or job ID is often safer than passing all the business data directly. The server-side script can retrieve the authoritative information from the hosted database and record the result of the operation.
PSoS expertise from fmcloud.fm
PSoS is often a great way to optimize a FileMaker application performance.
PSoS performance depends on both the FileMaker application and the server on which it runs.
At fmcloud.fm, we combine FileMaker development expertise with managed FileMaker Server infrastructure. We can help identify which operations should be delegated to the server, optimize existing PSoS scripts, implement job queues, and design controlled parallel-processing architectures.
We can also investigate issues involving FMSE queues, multiple SASE processes, record locking, server resources, API calls, and scripts that behave differently on FileMaker Server than in FileMaker Pro.
This combined expertise helps ensure that PSoS genuinely improves the application rather than simply moving a performance problem from the client to the server.
