Concepts

The words this guide uses for the parts of Spider, and how they fit together. Read this once before the tutorial; the glossary in the appendix is there to look things up later.

How it fits together

You describe a piece of work as a process definition: a diagram of steps, drawn in the designer. While you build it, you work on its draft. When it is ready, you publish the draft as a version.

Someone starts the process by hand, or a trigger starts it when something happens. Either way, Spider makes a process run: it follows the diagram from its start to its end, one node at a time, in one environment. Each activity in the diagram is handed to an agent, a computer that does the actual work, such as reading a mailbox or filling in a web form.

The activities come from integration modules. Activities that reach another system, such as a mailbox, use a connection that holds the login for it.

Organization

Everything in this part belongs to one organization: its process definitions, runs, triggers, types, collections, connections and environments. Another organization on the same Spider server sees none of it. You may belong to more than one organization; the header shows which one you are working in. See Signing in.

Process definition

A process definition is a process as you designed it: its diagram, and the parts the diagram uses:

• its variables, the values a run works with;
• its templates, texts such as the body of an e-mail;
• its milestones and reports, which tell the people following a run how far it got;
• its forms, which people fill in during a run or to start one;
• its demands, what an agent needs to run its activities.

A definition is the same in every environment. It can't be deleted. The Processes page lists them: see Processes.

Draft

You never change a published version. You change the definition's draft, in the Designer, and publish it when it is ready.

• A new definition starts as a draft.
• Edit on a published definition makes a draft from its latest version, after asking. A definition has one draft at most.
• Every change to a draft is saved at once. There is no Save button, and no undo.
• You can start a run of the draft to try it out (Use draft version), without publishing it. A draft is not started in production unless you choose production yourself: see Environments.

Version and publishing

Publish turns the draft into a new version of the definition, and the draft is gone. Versions are numbered major.minor, such as 1.0 or 1.1: you choose a major version for a change that people should notice, such as a new parameter, and a minor version for a small change.

• Publish is possible only when the process has no errors. The designer checks the process while you work, and says No errors or lists what is wrong.
• Runs started from then on run the new version. A run that has started already keeps the version it started with, to its end.
• Every published version stays on the definition's Versions tab, where you can look at it again.

Nodes and links

The diagram is made of nodes, connected by links. A run follows the links from one node to the next.

Node	What it does
Start event	Where a run begins.
End event	Where a run, or a branch of it, ends.
Terminate end event	Ends the whole run at once, from inside a sub-process.
Exclusive gateway	Takes one of its outgoing links, the first whose condition holds.
Inclusive gateway	Takes every outgoing link whose condition holds.
Parallel gateway	Takes all its outgoing links at once, or waits until all its incoming links are done.
Activity	Does one step of the work: see below.
Sub-process	A process of its own inside this one, with its own diagram.
Start process run	Starts a run of another process definition.

Activities, sub-processes and Start process run can also loop: they run once for each item of a list. A loop is a setting of the node, not a node of its own: see Sub-processes and loops. There are no timer or message events inside a process: what waits for a moment or a message is a trigger.

Each kind of node, and how they may be linked, is explained in The designer and its palette.

Activity

An activity is one step of real work: set a variable, send an e-mail, read a file, fill in a form on a website. Each activity comes from an integration module, and does what its module made it for.

• Inputs are what the activity needs, such as the text to write. Each input is filled in with a value, a variable, or an expression.
• Outputs are what it gives back, such as the e-mail it read. You choose the variable each output goes into.

Spider works out an activity's inputs, then hands it to an agent to run. Events, gateways and sub-processes need no agent: Spider runs those itself. See Activities and connections, Inputs and Outputs.

Variables and parameters

A variable holds a value while a run goes on: a name, an amount, an e-mail, a file. Each variable has a Name and a Type, and is either one value or a list of them (This variable is an array). A variable's name may contain only letters, digits, underscores and hyphens.

A parameter is a variable whose value is given when the run starts: by the person who starts it, by a trigger, or by the run that starts it. You make a variable a parameter with Allow use of this variable as a parameter.

A run's variables, and their values, are on its Variables tab: see Process run. How to add variables and parameters, and which node can see which, is in Variables and parameters.

Types

Every variable, input and output has a type. Spider has built-in types, such as String, Integer, Decimal, Boolean, DateTime, File and Email. An organization adds its own on the Types page: a simple type, such as a Country code that is a String, or a complex type with properties, such as a Shipment with a reference and a customer. Integration modules bring types of their own too. See Types, and the Types page.

Expressions

An expression works out a value while the run goes on. {Name} reads the variable Name, and functions combine values: concat("Hello, ", {Name}, "!") joins three texts into one, such as Hello, World!. An expression can be an activity's input, a gateway's condition, or a row of a mapping. See Expressions.

An input can be filled in other ways too: with one variable, with a fixed value (a literal), with a template, or by mapping values onto the properties the input needs. You choose the way next to the input: see Inputs.

Process run

A process run is one time a process definition ran, or runs. It has:

• a reference, such as 20261022.0002: the day it was created and a number that counts up;
• the version it runs, or the draft;
• the environment it runs in;
• a status, such as Running, Waiting for an agent, Succeeded or Failed: see Statuses;
• its logs, with a log for each node it ran, and its variables and their values.

A failed run is not the end: you can fix what went wrong, retry it, or abort it. See Running and monitoring, and the Process run page.

Trigger

A trigger starts runs by itself, when something happens:

• a Timer trigger, at the times of its schedule;
• a Webhook trigger, when another system posts data to its address;
• a Form trigger, when someone submits its form;
• a trigger from an integration module, when the module notices something, such as a new e-mail.

Each time a trigger fires, it makes a trigger run, which starts the process run or runs, with the parameters the trigger gives them. A trigger belongs to one environment. See Triggers, and the Triggers page.

Agent

An agent is a computer, or a container, that runs activities. It stays connected to Spider, runs the activities Spider gives it, and reports their outputs and logs back. An agent can be an organization's own, or shared by every organization on the server.

• Capabilities say what an agent has, such as a browser of a given version.
• Demands say what an activity, or a whole process, needs. Spider gives an activity only to an agent whose capabilities meet its demands.
• An agent-pool is a group of agents that work as one and share their capabilities.

While no agent can take an activity, because none is connected, free, or meets its demands, the run is Waiting for an agent. It goes on by itself once one can. See Agents, agent-pools and demands. Agents are managed by administrators: see Agents.

Environment

An environment keeps the runs, trigger runs, collection items, counter values and connection settings of one stage, such as Test or Production, apart from the others. You try a change out in a test environment, and production does the real work. A run always runs in an environment, so an organization needs at least one before it can start runs. See Environments.

Integration module

An integration module brings activities, triggers, types and kinds of connection to Spider: the Spider module has the basic activities, such as Set Variable, WriteLine and those for collections and counters, and other modules reach other systems, such as e-mail or AI-Hub. An administrator uploads a module once for the whole server; each organization activates the modules it uses, and the designer offers the activities of those only. See Integration Modules.

Connection

A connection holds what an activity or trigger needs to reach another system, such as the address and login of a mailbox. It holds them once for each environment, so a run in Test can use a test mailbox. You pick the connection in the activity's inputs: see Connections, and the Connections page.

Glossary

The glossary, with every term this guide uses and where it is explained, is in the reference appendix: see Glossary.