Deprecated process features

This section describes little-used features of the process support that have been superceded.

Sub processes

Each process can also be called as a script. In this case, it looks for the action in the config attribute for an initial action to run, rather than the request attribute. (It uses the presence of the data attribute to determine whether to look in the requests attribute or the config attribute.)

The sub process may change the data. The state and return values from the last script in the sub process will be the state and return value from the sub process.

A task script may invoke an action on its own process using the following:


Application attributes, such as data and request, will be available to the action.

The same convention can be used to invoke a process through application call() or execute(), for example the following code executes the process associated with a node and runs the display action.


Data persistence

Of itself, a process does not persist data, though the tasks are free to write data as required. However, standard tasks are available to assist with data persistence.

Save data

Save the data attribute, either to the context node or to a temporary node.

Load data

Load previously saved data into the "data" attribute.

Delete data node

Delete the data node identified by application attribute "dataNode".

The data persistence tasks are useful when the process supports user interaction. In outline, to interact with the user:

  • Use Save data to save the data.
  • Run a task that creates a response with content. The links or forms with which the user restarts the process should pass the reference of the data node in the request parameter "data".
  • When restarting the process, use Load data to reload the saved data.

Process instance

The Process Instance can be used to create instances of processes. The process is run when the instance is executed. They provide a Data member for the process to save data.

Other types can be created based on Process Instance.

Progress indicator

More complex processes may benefit from a progress indicator to entertain and inform the user while the process is in progress.

See the Progress Indicator Script for general introduction to the progress indicator. Task scripts are available to support the progress indicator process.

Start progress

Start or restart a progress indicator, and set a redirect to the progress indicator node.

Show progress

Write a message to the progress indicator.

End progress

End the progress indicator, optionally redirecting to a URL.

Progress error

End the progress indicator with an error read from the application error fields, optionally redirecting to a URL

Render progress

Standard script to render the progress indicator. This must be present in the process with an action name of "renderProgress".

Check for progress indicator

Test whether a progress indicator should be shown.

Execute in background

Re-execute the current context in the background. This is used to continue the process in the background after starting a progress indicator.

End progress with execute

End the progress indicator, redirecting to an execute of the current context.

Response handling

Task scripts can output a response to the user in the standard way, setting the title, head and content of the response.

However, it is sometimes useful to bulid a response in one script and then output it in another. For example, it can be useful to build a response in a background script, and then end a progress indicator with a redirect to an action that shows the response. You can achieve this by saving the response to the data area, and then rebuliding the response from the data area later in the process.

Two tasks scripts are available.

Copy response to data

Copy a response to the data attribute.

Copy data to response

Recreate a response that has previously been copied to the data area.

Copy data to response can also be used to output a response built up by previous scripts in the data.response object. This can be useful if a process uses multiple tasks to build a page to send to the user.


Of itself, a process does nothing about authority. All the tasks run under the authority of whichever user called the process.

For executed scripts, it can be useful to run the process under the node owner's authority. You can achieve this by calling the process as a script from a wrapper script, and preceding the call with application.runAsOwner().

In many cases, the process will want to know about the original caller, and may want to call services using the original caller's credentials. In this case, the wrapper script can use the Caller Credentials Script. This provides two methods:

  • store() – store the current user as a Script User object in the application attribute "user" and their credentials as a Service Credentials object in application attribute "credentials".
  • remove() – cancel the credentials and remove the "user" and "credentials" application attributes.

The wrapper script below will run the process bound to 'process' as the node owner, but with access to the caller in the "user" and "credentials" attributes.

application.include(application.getBinding('scriptCallerCredentials')); // bind to Caller Credentials Script;

Caller Credentials Script also provides more granular methods for storing and removing just the user or just the credentials.

Looking up processes using dynamic bindings

In complex solutions, processes and status rules (see below) may be identified by dynamic bindings.

Derive Process And Status Rules is a specialised type for creating a derivation field that will look up a process and status rules using dynamic bindings, and write them to Process and Status rules (library.process.StatusRulesLink, not library.process.StatusRules) respectively, taking defaults specified on the derivation field. Add this to the types in a solution so that the instances of those types will have Process and Status rules populated.