Skip to main content


What is an App?

An app in PIPEFORCE is like an app for mobile phones. Such an app groups together resources like scripts, templates, configurations and others to solve a certain business task. Any pipeline, form or workflow etc. is part of exactly one app.

An app can be shared with others on the marketplace.

Also see this tutorial to learn how to create an app in PIPEFORCE.

For each app, certain access rules can be specified. Apps can be installed, uninstalled, exported and imported. Furthermore, it is also possible to use staging and versioning for apps. They can be developed online using the workbench or offline using source code files and the CLI. You can think of apps also like “plug-ins” for PIPEFORCE.

App structure

Typically, all properties (resources) of an app reside in the property store and having a property path with a prefix like this:


The path always starts with prefix global/app, followed by the name of the app <NAME>, wheras <NAME> must be a fully qualified, unique name.

Qualified App naming

In order to avoid a naming clash with other apps from other users which could probably have the same naming as your app, as best practise, you should give the app always a name which follows the reversed domain name package conventions from the Java package specification:

  1. The app name is written in lower case and may not contain any space or special character.
  2. Use the reversed internet domain name of your company, project or organisation to begin the app name. For example: com.logabit.myapp or org.myproject.myapp.
  3. Built-in apps from PIPEFORCE always start with prefix io.pipeforce. for example: io.pipeforce.common.
  4. Note: The internet domain names must be valid ones if you want your apps to become trusted in the marketplace.

Here is an example of a property path to a resource inside an app with fully qualified name:


App folders

Inside of an app path, there is a certain "folder" structure at app level which defines the main resource types of an app. The typical folder structure looks like this (the folders could vary, depending on your setup):


This folder contains all form configuration properties for any form of the app, whereas the name of the property is the name of the form. For example:



This folder contains all list configuration properties for any list of the app, whereas the name of the property is the name of the list. For example:



This folder contains any application model (schema) and its instances (if there are any).


The schema of an object is stored in a property having this path:


Whereas <NAME> is the name of the object.

<VERSION> is the version of the object schema.

For example:


The schema property typically contains as value a JSON schema, which describes this object. For the person object, the schema could, for example, look like this:

"type": "object",

"properties": {
"firstName": {
"type": "string"
"lastName": {
"type": "string"
"age": {
"type": "number"
"gender": {
"type": "string",
"enum": ["male", "female", "neutral"]

See the JSON schema specification for a description how to define JSON schema documents:


In case there are object instances based on a schema, they should be typically stored inside this path structure:


Whereas <NAME> is the name of the object.

<VERSION> is the version of the object schema.

<UUID> is the unique id of a single object.

For example:


Each instance property will contain as value the data of the object instance which matches the object schema, for example:

"firstName": "Homer",
"lastName": "Simpson",
"age": 48,
"gender": "male"


This folder contains all pipeline configurations for the given app. A pipeline can be seen as the business logic part of an application.

Find more about pipelines here

Each property name corresponds with the name of the pipeline and contains as value the pipeline configuration. For example:


Such a pipeline configuration could look like this:

- mail.send:
subject: "A new employee was addded!"


Inside of the optional script folder, scripts can be placed which can contain more complex business logic if required. By default, such scripts are written in JavaScript. Optionally also Python or Groovy are available (ask if required). For example:


Such a script could look like this example:

function command() {

pi.message.headers["foo"] = "bar";
pi.message.body = "HELLO WORLD IN THE BODY";

var timestamp = pi.util.timestamp();
pi.log.debug("Command script executed at: " + timestamp);

You can call such a script from a pipeline, like this example shows:

path: "global/app/myApp/script/helloworld"


This folder typically contains pipelines for tests only. Whenever necessary, PIPEFORCE automatically executes the test pipelines inside this folder to make sure the app is working as expected. Therefore you have to make sure that these tests can be executed at any time and are fully reentrant (once a test has been finished it can be executed again as often as necessary).

For example:


The property contains the test pipeline as value. Such a test pipeline could look like this:

- test:


This folder contains any BPMN workflow files defining a business process.

For example:


App development

In its simple case you can manage all properties of an app in the property store with the property.* commands and the CLI using pi pipeline or using the online workbench.

But if you want to develop complex apps with forms, pipelines or workflows inside, we recommend you to use a local development & customization workspace. This workspace contains the properties of such an app stored as files inside a local folder. Any file created inside this folder can then easily be uploaded to the property store with a single command line call using the CLI. For example:

pi publish

This CLI command scans your local folder and uploads only those resources which have been changed since the last upload or have been created since then. See here how to setup the CLI and how to create a local worskspace: Local Low-Code Workspace

Report an Issue

Your help is needed!

In case you're missing something on this page, you found an error or you have an idea for improvement, please click here to create a new issue. Another way to contribute is, to click Edit this page below and directly add your changes in GitHub. Many thanks for your contribution in order to improve PIPEFORCE!