Flow step reference

This reference describes every step available in the Flow builder — what each one does, what you configure, and how steps connect to each other.

How steps connect

Each step in a flow has an input port and an output port. The canvas only lets you draw a connection between two steps when their ports match. Every step also accepts exactly one incoming connection — while you drag an edge toward a step that already has one, the canvas refuses to attach it. The three port types are:

• Photo — a photo, optionally with its background removed and face detected. Flows start here.
• Render — a finished image file (from Create Image or Create Editable Design & Render).
• Design — an editable design in Studio (from Create Editable Design Only or Create Team Photo).

The Photos step (start) is permanent and cannot be removed. Every other step is dragged from the Steps palette on the left. The palette is organized into labeled sections — Photo, Format, Logic, Design, and Send & route — that group the steps by what they do. The Photo group holds Remove Background and, for organizations with Glare Removal enabled, Remove Glare.

A few steps are terminal — they end a path and pass nothing downstream. Send To, Run Flow, and Call Service each finish a branch.

Photos (start step)

The Photos step is always the first step of a flow. It defines where photos come from and carries any per-photo data (name, jersey number, team) into downstream steps.

How the flow starts

A Trigger dropdown at the top of the panel offers three options: Photos (manual upload), Templified Tether or Studio drop, and External system (GFITpro / webhook).

Manual upload is the default: the photo grid and Data CSV section appear immediately, so you drop photos in, attach an optional CSV, and press Run. This is the path for batch work you kick off yourself, and it's all most flows need.

Choose Templified Tether or Studio drop when photos should reach the flow without anyone opening the flow builder — the panel explains it as Photos captured in the Templified Tether app — or dragged onto one of the event's Studio folders — run this flow automatically. Both routes arrive the same way, so one setting covers app captures and drag-and-drop alike. Choose External system (GFITpro / webhook) when another system should send photos to the flow automatically — each incoming photo starts its own run.

Photos (manual mode)

Click Add photos to upload JPEG, PNG, or WebP files. The photos appear as a thumbnail grid. Click Clear all to remove all photos at once.

Data CSV (manual mode)

Optionally upload a CSV file to attach per-photo text fields — player name, jersey number, team, or any other column. Every column becomes a {Column} variable you can insert into text fields on any downstream create step.

Once a CSV is loaded, a Match photos on picker names the column photos are matched by. Templified guesses it from the headers (filename, file, photo, image, and headers containing those words, such as Card Image), but the picker is always shown and you can change it at any time without re-uploading. The list also offers No filename column for a CSV that genuinely has none.

When nothing filename-like is detected, the picker escalates to an amber No filename column found warning: Photos are matched to rows by filename. Until you pick the column holding the filenames, photos won't match any row and their text fields will fall back to the template's defaults. Pick the right column and the warning clears.

Matching is forgiving. It ignores case, compares just the file name (any folder path is stripped), and tolerates a different image extension — so player1.jpg matches a cell holding player1 or player1.png. That means a human-meaningful column can do the matching.

The match column stays available as a variable too. Because it is no longer withheld from the variable list, a column such as Card Name can both match the photos and print on the design as {Card Name}, and it appears alongside the other columns as a per-photo field.

Download a sample CSV from the link in the config panel to see the expected format.

Templified Tether or Studio drop

There is nothing to configure. The Templified Tether app links itself to your organization when your team signs in, so captures from the app — and photos dragged onto one of the event's Studio folders — run this flow automatically. The panel just reports status: a Templified Tether section confirms Connected — use the Templified Tether app on your iPhone or iPad, then tells you whether this flow is your default flow, is routed by a rule, or is not routed yet — with a Set as default flow button in that last case.

External trigger with a GFITpro connection

If your organization has a GFITpro connection, the external-trigger panel opens with a GFITpro connection section. Because GFITpro delivers photos to one address for your whole organization, what matters here is whether those photos reach this flow. The section reports one of three states:

• Default flow — this is your default flow: every GFITpro photo runs it unless a routing rule sends it elsewhere.
• Routed by a rule — a routing rule sends matching GFITpro photos to this flow.
• Not routed — GFITpro photos won't reach this flow yet. A Set as default flow button fixes that in one click. The default flow runs every photo that no routing rule claims; to route only some photos here, add a routing rule instead.

An Open Connection settings link jumps to the Connection tab of the Flows page, where the connection itself is managed. The connection section appears for owners and admins; members instead see the per-flow webhook settings with a note pointing them to the Flows page.

The per-flow webhook sits behind an Advanced: per-flow webhook disclosure below the connection section. The label gains an (enabled) suffix while the flow's webhook is active, and the disclosure opens pre-expanded in that case so a live webhook is never hidden.

Per-flow webhook

Without a GFITpro connection, choosing the external trigger shows the per-flow webhook settings directly:

1. URL — the endpoint your system POSTs to. Fixed per flow.
2. Token — a Bearer token for authentication. Click Generate token to create one; copy it and store it securely. You can Regenerate (invalidates the old token) or Revoke (disables the webhook) at any time.
3. Fields — declare the names of the data fields your request will include (for example: Player First, Player Last, Team). These become {Player First} etc. in downstream steps.
4. cURL example — a ready-to-copy cURL snippet showing the exact request shape, with your token and declared fields filled in.

Send one photo per request. Each request triggers an independent run for that photo.

The per-flow webhook is a legacy trigger — its URL changes whenever you rebuild the flow. For an external trigger, prefer your organization's Connection URL (Flows → Connection), a single stable address that never changes.

Run-time colors

A Run-time colors section sits at the bottom of the Photos step, whichever trigger you chose. It is where you name the colors someone is asked for when a run is launched — hinted Colors someone picks when photos are dropped into an event that runs this flow. Each one is a variable a Create step can assign to a layer.

[Screenshot coming: Run-time colors on the Photos step with a Team color row and its token, beside a create step's Colors section listing layers set to Template, Color, and Variable]

Click Add run-time color to add a row, then:

1. Type a label — the wording the person launching the run will see (for example Team color).
2. Each row derives a {key} token from that label and shows it next to the row: Team color becomes {teamColor}. That token is what you bind to a layer further down the flow.
3. Optionally set a Default color with Set, or clear it again with None.

These are the colors the Studio drop dialog prompts for, under Colors for this batch. A run that nobody starts by hand — a Tether capture, a webhook, or a GFITpro photo — never sees the prompt and uses the declared default instead; with no default, the layer simply keeps the template's own color.

Before you add any, the section reads None yet. Add one to ask for a color when photos are dropped into an event, then use it as a variable in a Create step's Colors.

Remove Glare

Input: Photo · Output: Photo

Removes glasses glare from photos. The step checks each photo for glasses automatically and sends only the glasses photos for correction — photos without glasses pass through unchanged. Each corrected photo is billed by Skylab to your organization's own Skylab account.

Place it right after Photos, before Remove Background — that way each photo needs only one Background Removal. Placing it after Remove Background also works: the corrected photo automatically has its background removed again, which is a second Background Removal for that photo.

Configuration

• Only photos with glasses (toggle, on by default) — sends only photos where glasses are detected. Turn it off to send every photo — each one is billed, whether or not it has glasses.
• Label (optional) — a display name to make the step easy to recognize on the canvas.

The step requires your organization's Skylab (Captura Enhance) account connected in Settings → Integrations, and it appears in the palette only for organizations with Glare Removal enabled. See Removing glasses glare in a flow (Skylab / Captura Enhance) for setup and billing details.

Remove Background

Input: Photo · Output: Background removed photo

Cuts the subject out of the photo and detects the face and content area. Downstream steps — especially photo layers with face placement — use the detected bounding boxes to position and scale the subject automatically.

One optional setting is available: Color correction (toggle). When on, color and tone adjustments are applied to help the cut-out blend naturally into different backgrounds.

Background Removal is charged per photo processed. Re-running a flow on photos that were already processed in a previous run reuses the cached result at no additional charge.

Text

Input: Text · Output: Text

Derives a new per-photo field from an existing one. Use it to pull a useful sub-value out of a larger string before it reaches a create step. For example, extract Week 1 from a long event string, or take a player's last name from a combined full-name field.

The step does not modify the photo — it passes the photo through and adds the new variable alongside any existing ones.

Configuration

• Source field — pick an upstream variable (from a CSV column, a webhook field, or a previous Text step) to transform.
• Operation — choose the transform type:
  • Regex extract — runs a regular expression. The first capture group (the part inside parentheses) becomes the output; if there are no capture groups, the whole match is used.
  • Split — splits the value on a literal string you provide, then picks which part to keep (set Part # to 1 for the first part, 2 for the second, and so on).
• Output field — name the new variable. Use it in any downstream step as {OutputFieldName}.
• Preview — paste a sample value to see what the transform produces before you run the flow.

Format Date

Input: Photo · Output: Photo

Derives a formatted date or ISO week number into a new per-photo field. Use it to stamp a game date or week label onto a design automatically instead of typing it for every photo. Like the Text step, it passes the photo through unchanged and adds the new variable alongside any existing ones.

Configuration

• Date source — pick an upstream date value to format, or choose Current time to use the moment the flow runs.
• Output — choose Formatted date for a calendar date, or Week number (ISO) for the ISO week number.
• Format — for a formatted date, the pattern the value is written in (for example YYYY-MM-DD). This option is hidden for week-number output.
• Output field — name the new variable. Use it in any downstream step as {OutputFieldName}.

Branch

Input: Photo · Output: Photo

Routes each photo down one of several paths based on its fields, so a single flow can handle different cases — for example, sending home-team and away-team photos to different templates. The photo itself passes through unchanged; only the path it takes changes.

Configuration

Add one or more routes. Each route has a name and one or more conditions — a field, a test (such as equals, contains, or is empty), and, where the test needs one, a value. A photo takes the first route whose conditions all match; any photo that matches no route takes the Else output.

Each route — and the Else output — is a separate output connector that sits on the step's edge beside its route label, so drag from the connector next to the route you want. Connect every one to a downstream step; the flow warns you if a declared route has no connection.

Filter

Input: Photo · Output: Photo

Lets a photo continue only when it matches a condition, and drops the rest. Use it to skip photos that shouldn't be processed — for example, continue only rows whose Status equals Approved.

Configuration

Set a single condition: a field, a test, and, where the test needs one, a value. Photos that match continue to the next step; photos that don't are dropped and go no further in the flow.

Create Image

Input: Photo · Output: Render

Renders a template into a finished image file. The photo from the pipeline fills the template's photo layer; text fields are filled from your CSV columns, webhook fields, or Text step outputs.

Configuration

1. Pick a Template. The picker browses by folder: choose a folder to see the templates in it, and use the search box to filter within that folder. A Recent section lists your recently used templates from other folders so you can jump straight to them, and long lists scroll. Once a template is chosen the picker collapses to show its name — click Change to pick a different one.
2. The Text fields section lists every dynamic text layer in the template. For each field, type a fixed value or click the {} button to insert a variable. Fields that share a name with a CSV column are auto-filled with the matching variable.
3. A QR codes section lists every dynamic QR layer in the template. For each one, type the exact value to encode — a link or plain text — or click the {} button to insert a variable. A {Column} token resolves per photo, so each design's QR code can point at that player's own link (for example https://site.com/{barcode}). Leave a field blank to keep the template's own value. QR fields whose name matches a CSV column or webhook field are auto-filled with the matching variable, exactly like text fields. The section only appears when the template has dynamic QR layers.
4. Photo layers are filled automatically by the pipeline photo — they appear in the list as read-only reminders.
5. Set a Player ID (the field suggests e.g. {barcode}) to identify each photo's player. It sits in the panel directly, no longer behind a disclosure.

[Screenshot coming: Create step config panel showing the QR codes section with a variable token and the GFcrew codes section below it]

Every create step also has a GFcrew codes section — hinted Which GFcrew event this design belongs to, and where its export lands — holding GFcrew main event code and GFcrew destination event code. These are ordinary fields in the panel now rather than an Advanced disclosure, and like text fields they accept {Column} variables, which resolve per photo from your CSV columns or webhook fields.

Create Image has no Colors section — recoloring layers is available on the steps that save an editable design (Create Editable Design Only, Create Editable Design & Render, and Create Team Photo).

⚠️ REVIEWER: confirm Colors is intentionally unavailable on Create Image — the Colors section is currently shown only on the create steps that save an editable design.

A finished image is not stored as a design in Studio. Route it to a destination using a Send To step, or it will only appear in the run results panel.

Create Editable Design Only

Input: Photo · Output: New Design

Creates an editable design in Studio for each photo, without rendering an image. The design opens in the Studio editor so you or your team can review, adjust, and send it manually.

Configuration

1. Pick a Template.
2. Fill Text fields, QR codes, and GFcrew codes the same way as Create Image.
3. Recolor layers in the Colors section (described below).
4. Under Output: set a Folder path where new designs land in Studio, and a Design name pattern. Both are required — each label carries an amber *, and until you fill it the field shows Required — the flow can't run until this is set. The flow will not validate or run until both are filled. Both fields show example values — Folder suggests e.g. {mainEvent}_MainEvent/Panos and Design name suggests e.g. {firstName} {lastName} — and both accept your own variables, so each design is named and filed automatically.
5. Set a Player ID to identify each photo's player, as on Create Image.
6. Overwrite existing is on by default: re-running the flow on the same photos updates the existing designs in place rather than creating duplicates. Turn it off to create a new design on every run.

Colors

A Colors section appears once a template is chosen — hinted Recolor layers on the design: a fixed color, or a variable such as a run-time color from the Photos step. It lists every text, shape, and QR layer in the template, static ones included, so a fixed headline or a banner shape can take the team's color just as a dynamic field can.

Each layer shows the color properties its type has, and you set each one to Template, Color, or Variable:

• Template — leave the template's own color alone. This is the default for every property.
• Color — one fixed color, picked here and used on every design this step creates.
• Variable — bind a {token}, normally a run-time color declared on the Photos step, so the color changes from run to run. This option is unavailable until the flow has variables to offer.

Which properties you see depends on the layer type:

Layer type	Color properties
Text	Fill, Stroke
Shape	Fill, Stroke
QR	Foreground, Background

If the Photos step declares no run-time colors yet, the section reminds you to add one there first and then choose Variable here, and notes that Color sets one fixed color. A template with nothing to recolor shows This template has no text, shape, or QR layers to recolor.

Create Editable Design & Render

Input: Photo · Output: Render

Creates an editable design in Studio and renders it in a single step. You get the benefit of both create steps: the design is saved to Studio so you or your team can reopen and adjust it later, while a finished image is produced immediately. Because this step outputs a finished render, a downstream Send To dispatches that already-rendered image with no second render.

Configuration

1. Pick a Template.
2. Fill Text fields, QR codes, and GFcrew codes the same way as Create Image, and recolor layers in the Colors section exactly as on Create Editable Design Only.
3. Under Output: set a Folder path and a Design name pattern for the design saved to Studio. Both are required — marked with an amber * and warning Required — the flow can't run until this is set. until filled — and the flow will not validate or run until both are set. Overwrite existing is on by default, so re-runs update matching designs in place. A Player ID field sits here too.

Set the finished file's destination on a downstream Send To step.

Create Team Photo

Input: Photo (one photo or a whole run) · Output: Design

Composes individual player photos into a team-layout template, producing a single editable design containing the full team. It works two ways, depending on how photos reach it:

• Whole run at once — when a run contains several photos (a manual upload), the step waits for every photo in the run to arrive, then places them all into the team layout in one pass.
• One photo at a time — when photos arrive in single-photo runs (for example through the GFITpro connection), each run appends its photo to the team design named in the step. The design is created when the first photo arrives, and each later photo fills the next open slot.

Configuration

1. Pick a Template — it should be a team-layout template with multiple photo slots.
2. Fill any Text fields (for example, a team name or season), plus QR codes and GFcrew codes as on Create Image. A Colors section is here too, working exactly as on Create Editable Design Only. When a photo appends to an existing design, the text fields are re-applied — so a value that only arrives with a later photo still lands on the design.
3. Set a Folder and Design name for the resulting Studio design. Both are required — each label carries an amber *, and an empty one warns Required — the flow can't run until this is set. The flow will not validate or run until both are filled. Appended photos find their design by folder, name, and template, so use a variable in the name (the field suggests e.g. {teamName}) and each team collects into its own design.
4. Set Player ID (the field suggests e.g. {barcode}) to identify each player's photo. It sits in the Output section directly — it is no longer behind an Advanced disclosure — with copy explaining that when photos arrive one at a time, each run appends to the design named above, and a photo whose Player ID matches an already filled slot replaces that player's photo instead of adding a duplicate, so a reshoot updates the player's photo. Leave it blank and every photo takes the next open slot, so a reshoot adds a second photo of the same player.

Roster players created in the app or imported by CSV are now given a barcode automatically, so with Player ID set to {barcode} a reshoot of that player replaces their existing photo rather than adding a second one.

Either way, the step produces one design per named team, no matter how many photos feed it. Any step downstream of it applies to that single team design.

Run Flow

Input: Photo · Output: none (terminal)

Hands each photo off to another flow to finish processing. Use it to keep a shared set of steps in one reusable flow and call it from several others, instead of rebuilding the same tail end everywhere. This step is terminal — the photo leaves for the other flow, so nothing runs after it in the current flow.

Configuration

Pick the flow to hand each photo to. The chosen flow runs on the incoming photo and its fields.

Call Service

Input: Photo · Output: none (terminal)

Sends each photo to an external service for further handling. This step is terminal — the photo is dispatched to the service, and nothing runs after it in the current flow.

Configuration

The service destination is set up for your account ahead of time, so no address or credentials live in the flow itself. You can optionally set a display label to make the step easy to recognize on the canvas.

Send To

Input: Design or Render · Output: To the destination

Dispatches the upstream result to a destination. It is always the last step in a branch.

Destination options

The Destination picker shows two groups:

• Presets — your configured Send-To presets. Use a preset when the upstream step is Create Editable Design Only or Create Team Photo. The preset's destinations (Dropbox, webhook, print location, etc.) receive the rendered output.
• Direct — connected integrations that can receive a finished render file directly. This option appears only for Dropbox and webhook integrations, and only when the upstream step is Create Image or Create Editable Design & Render. Configure integrations in Settings → Send-To.

Step connection rules

Step	Accepts	Produces
Photos (start)	—	Photo
Remove Glare	Photo	Photo
Remove Background	Photo	Photo
Text	Photo	Photo
Format Date	Photo	Photo
Branch	Photo	Photo
Filter	Photo	Photo
Create Image	Photo	Render
Create Editable Design Only	Photo	Editable Design
Create Editable Design & Render	Photo	Render
Create Team Photo	Photo	Editable Design
Run Flow	Photo	—
Call Service	Photo	—
Send To	Design or Render	—

The canvas prevents invalid connections — if a step's output port does not match the next step's accepted input, you will not be able to draw the edge.

Related articles

• Flows overview: building a pipeline
• Background Removal & photo enhancement: overview
• Removing glasses glare in a flow (Skylab / Captura Enhance)
• Send-To presets and destinations
• Setting up a Send-To destination (Dropbox, webhook, print)
• Face placement overview