Learning Outcomes

Open the batch import wizard from a pipeline's workflow sidebar.
Scan a repository and read what each of the six statuses means.
Search, filter and select the processes you want, one revision each.
Read the consent step before you commit to an import.
Read the results step, and know why running a batch again is safe.

Process Guide

Importing many processes from a repository, at once

A repository can publish more than one process. Instead of running the import wizard once per process, picking each one from a plain list of slugs, you can scan the whole repository and see every process it publishes in one table, with real information about each one and a status telling you whether it can be imported. You then select as many as you want and import them under a single consent.

Opening the wizard

Open a pipeline and go to its Workflow tab. In the left sidebar, click Import Process from Git. This is the same action that opened the import wizard before; what changed is what happens after you point it at a repository.

Scanning a repository

The first step, Source, asks for the Repository URL, the Provider (github, gitlab or bitbucket), and, if the repository is private, a Credential you have already configured under Profile → Integration Tokens. Click Check repository to scan it.

The scan reads every process the repository publishes and checks each one against what this installation already has, before anything is imported. A repository that fails the scan (for example, one that does not use Foundry's expected layout) is refused with a message explaining why, and nothing is imported.

Enter the repository's current URL. Foundry does not follow a redirect from one repository address to another, so a repository that was renamed or moved on its host has to be scanned at its new address; pointing the wizard at the old one is refused:

The repository URL redirects to a different address, and Foundry does not follow redirects when importing from git. If the repository was renamed or moved, enter its current URL.

Reading the table

Once the scan finishes, the Pick step shows one row per process (or, with history expanded, one row per process revision; see Latest revision only below). Each row carries the process's name and slug, its summary, its revision number, how many inputs and outputs it declares, its fidelity level, whether it carries any assets, and the date it was committed.

Every row also carries a status, shown as a badge:

Status	What it means	Can you select it?
New	Nothing here matches this process yet.	Yes
Update available	This process already exists here, whether as a live process or as one whose every revision has since been deleted, just not at this exact revision. Importing another revision into an existing process is not supported by a batch import.	No
Already imported	You already have a process with this exact content. Importing it again would only create a second copy.	No
UUID conflict	This revision's unique identifier already belongs to a different process here. Foundry refuses to import a second copy under the same identifier.	No
Contract refused	The process definition parses, but Foundry's import checks refuse it.	No
Unreadable	The process definition could not be parsed at all.	No

Only rows marked New can be selected. Every other row is shown greyed out with its checkbox disabled, the status badge, and a short reason underneath explaining why, so you can see what is wrong rather than just seeing the row refuse to respond. A row that is already imported, in conflict, or has an update available also shows the process number of the process already here (for example "Process #482"), when one still exists, as plain text rather than a link, so you know which existing process the row refers to. An update available row whose earlier import has since been deleted entirely names that in its reason instead, with no process number to show.

One bad process never sinks the scan of an otherwise good repository. A process that fails to parse is simply reported as Unreadable, and every other row in the table is unaffected.

Search, facets and revision history

Above the table:

Search matches a process's slug, name and summary, case insensitive.
Facets let you filter by status, fidelity level, and whether a process has assets. Chips within one facet are combined with OR (matching any of the chips you pick), and facets are combined with AND (a row has to satisfy every facet you have set).
Latest revision only is a toggle, on by default. With it on, the scan reads only the newest revision of each process, which is what collapses a repository publishing many revisions of the same processes down to one row per process. Turning it off re-scans the repository and gives every revision its own row, which is how you reach an older revision. While that re-scan runs, "Scanning the repository..." shows beside the toggle and the toggle is disabled until it finishes. There is no per-row dropdown for choosing a revision: since the details shown for a row come only from the revision the scan actually read, a dropdown offering revisions the scan never read would show the wrong name, hash and status for anything except the row's default.

Selecting processes

Above the table, Select all, Select none and Invert act on whatever the current search and facets show, and all three skip rows that are not selectable. The count next to them, "N of cap selected", always shows how many you have picked against the batch limit (see Two administrator configured limits below).

Only one revision of a process can be selected at a time. With Latest revision only turned off, a process's revisions appear as independent rows, and selecting two revisions of the same process would import it twice as two unrelated processes rather than as a revision history, which this wizard does not do. Selecting one revision of a process disables the checkbox on every other revision of that same process, with the reason "another revision of this process is selected" shown underneath. Select all and Invert apply the same rule automatically, always keeping the highest revision of each process rather than adding more than one.

Once your selection reaches the batch limit, every remaining selectable checkbox is disabled with the reason "the batch cap of N has been reached" shown underneath, and Select all stops adding further rows once it hits the same limit. Clearing a row you already selected frees up a slot.

Click Continue once you have selected at least one process.

The Consent step is where you commit to the import. First, choose a Menu group from the dropdown (placeholder: "Select a menu group"). Every process imported in this batch is placed under this one menu group. The chosen group is checked again at import time, and the batch refuses, before anything is imported, if it no longer exists or is not a menu group for processes.

Below that, Foundry lists what you are about to import: the repository URL, how many processes, and then one entry per selected process naming it, its slug and revision number, and the full commit id it will be imported from. The text states plainly that Foundry will store this code but will not execute it, and that you should review it before using it, followed by:

Each process is checked again at import time, and any that fails is reported rather than imported.

That sentence is there because it is true: between the scan and the moment you click Import, the repository could have changed, or someone else could have imported one of the same processes. Every item in the batch is checked again, individually, right before it is written. An item that no longer checks out is not imported; it is reported as skipped or failed on the results step instead, with the reason.

Tick the checkbox, "I have read the source and understand this code will be stored but not executed," and click Import. The button stays disabled until the box is ticked and a menu group is chosen.

While the import is running, the Consent step shows:

Importing N processes. This window stays open until the import finishes, so you can see what happened to each one.

The wizard cannot be closed while this is shown: the close button is hidden, and pressing Escape or clicking outside the wizard does nothing. This is deliberate. The window stays open only long enough to show you the per process results below; closing partway through would lose that report even though the processes already handled stay imported and audited either way. Once the batch finishes, the wizard moves on to Results on its own and the close button returns.

If the request times out or the connection is lost before Foundry answers, the wizard cannot tell you what happened, and says so instead of guessing:

Foundry did not answer in time, so this page cannot tell which processes were imported. Some may already be imported. Scan the repository again to see which.

The consent checkbox is unticked and Import stays disabled, replaced by a Scan again button, so you cannot resend the same batch with one click while Foundry may still be working through it. Scanning the repository again shows you exactly what is there: anything that was already imported comes back as Already imported.

Results

The last step reports what actually happened, one line per process, grouped under Imported, Skipped and Failed headings (each shown only when it has at least one entry). The summary line at the top reads "Imported x of y process(es)," because a batch can finish partially: consenting to twenty five processes does not guarantee you get twenty five back, for exactly the reason the consent step named. This is expected, not a failure of the wizard.

Every row, whatever its outcome, names the process first, then its slug and revision number.

An imported row also names its new process number.
A skipped row is a process that failed its recheck for a reason that is a correct refusal rather than an error, for example the commit it pointed to moved, or the process is no longer new since you started the batch. The server's message is shown underneath, as given.
A failed row covers anything else that went wrong, with the server's message shown underneath, as given.

From here, Run again takes you back to the Source step with the repository URL kept, so re-scanning the same repository is one click away. Running the same batch again is safe: anything you already imported now comes back from a fresh scan reliably marked Already imported, with the reason described in Reading the table above, rather than being imported a second time. Done closes the wizard.

Two administrator configured limits

Two limits keep a scan or a batch from growing without bound. Both are set by your installation's administrator, and both refuse with the real count when you go over them rather than silently cutting your request down:

A scan looks at up to 200 process revisions by default. A repository publishing more processes (or more revisions, with Latest revision only turned off) than that will need the limit raised by an administrator before it can be scanned in full.
A batch import applies up to 25 processes at a time by default. If you need to import more than that from one repository, run the wizard again for the rest, or ask an administrator to raise the limit.