Every apparel job that prints on a Kornit machine or a similar apparel machine needs a print configuration — a small XML file (a KSF, Kornit Submission File) or a similar XML/JSON file that tells the machine how to handle that specific garment: which colour profile to use, where the print area sits, what the offsets are, how much ink to lay down, and so on. Different garments need different configurations: a white t-shirt prints differently from a dark hoodie; a chest print is set up differently from a back print.
The Configurations tab on each apparel machine in Machine Park is where you keep these profiles. You can upload them as files, paste them in as XML, edit them, or delete them — no Support intervention, no JavaScript edits in workflows. Once a configuration exists here, it can be assigned to a product model (see the assignment article) and picked up automatically at print time by the Get KSF Configuration workflow activity.
Who this is for
You run a Apparel print machine (Atlas, Avalanche HD6, or similar) through GelatoConnect.
You need to add a new garment style that wasn't previously printed in your operation.
You're adjusting print offsets, colour profiles, or ink limits for an existing garment.
You're migrating off the old approach where KSF rules lived inside a workflow JavaScript activity.
Before you start
Your apparel machine is set up in Machine Park (Machine Park → Add machine → Kornit). If you don't see your machine, contact your Gelato representative.
You have the XML print profile you want to use. This usually comes from your existing Kornit workflow, from Kornit's own configuration tooling, or from a previous JavaScript-based setup that needs to be migrated.
Step 1 — Open the Configurations tab on your machine
In the left menu, go to Machine Park.
Find your machine in the list and click Edit on its row. Each machine has its own independent set of configurations.
In the edit panel, switch to the Configurations tab. The table is empty the first time you open it.
Step 2 — Add a configuration
Click Add configuration (or Add New Config, depending on your tenant).
Fill in the fields:
Name — a short, human-readable label. This is what you'll see when assigning the configuration to a product model. Examples: "Crewneck light sweatshirt," "Small coloured hoodie," "Gildan 5000 white," "AtlasZipperHoodie back print."
Description (optional) — anything that helps a colleague understand what this profile is for.
Type — XML. As of May 2026, XML is the only supported format; JSON is planned.
Config content — the profile itself, in one of two ways:
Upload an XML file from disk, or
Paste the XML inline into the editor — useful when copying from a colleague's screen.
Click Save. The configuration appears in the table and is available for assignment.
Step 3 (optional) — Use variables in the XML
If you need the same configuration to apply with different values for different products (for example, the same colour profile but a different X-offset per print location), put placeholder variables into the XML using double curly braces: {{offsetX}}, {{offsetY}}, and so on.
At runtime, the Get KSF Configuration workflow activity replaces each variable with the value you set on the activity. If the workflow doesn't provide a required variable, the request is rejected with an error naming the missing variable — so you'll never silently print with the wrong offset.
Use variables sparingly. Most operations work fine with one fixed configuration per garment style; variables are mainly useful when you have a family of similar products that only differ on a few numeric values.
Step 4 — A typical starter set
Most apparel operations end up with a configuration per garment-and-print-location combination. A typical starter set looks like:
Light garment — chest print — for white and pastel garments with a front chest print.
Light garment — back print — same colour family, different print area.
Dark garment — chest print — for black and saturated colours, usually with a different underbase.
Dark garment — back print
One or two style-specific overrides — for a particular Gildan SKU that needs its own offsets, for example.
If you're migrating from the old JavaScript-based workflow, the cleanest way is to pull each XML block out of the JS, paste it in as a configuration, and name it after the rule it used to satisfy.
Step 5 — Edit or remove a configuration
Edit — click the configuration row. Change the name, replace the XML by uploading a new file, or edit the XML inline. Save. The change applies the next time a workflow run resolves this configuration; in-flight jobs are unaffected.
Delete — click the delete icon at the end of the row. If the configuration is currently referenced by a product-model assignment, the system warns you. Update or remove the assignment first to avoid failures at the next workflow run.
Step 6 — Use the configuration in production
Once your configurations exist in Machine Park, two more places need to be set up so they actually get used:
Assign on the product model. Open the product model (or a customer product built on it), go to the Print Profiles / Machine Configurations tab, and add a rule. A rule says "for this combination of attributes — e.g. colour = dark + print location = back — use the Dark / back configuration." You can stack multiple rules and rank them by priority. See Assigning KSF print configurations to product models and variants (Apparel).
Add the workflow activity. In your apparel workflow, use the Get KSF Configuration activity instead of the legacy JavaScript activity. At order time, it pulls the right configuration from Machine Park, substitutes any variables, and outputs the XML to the next step. See Get KSF Configuration activity in Workflow Builder for dynamic apparel printing.
Tips
Update configurations here, not in workflows. Once your workflow uses Get KSF Configuration, you should never need to touch the workflow again to change a print profile.
Keep naming consistent — "Light garment — chest" beats "profile_v3_2026_03." Rules are easier to manage when the configuration name itself tells you what it's for.
Test on a single workflow first. Roll out on one machine and one low-volume product line, confirm it's clean, then expand.
Troubleshooting
"Variables not provided" error at runtime — the workflow's Get KSF Configuration activity isn't passing a variable that the XML expects. Either remove the {{variable}} from the XML, or add the missing value to the activity's Template Variables list.
Configuration disappears from the assignment dropdown — it was deleted from Machine Park. Re-add it here first, then re-attach it on the product model.
Wrong colour or offset on print — the configuration is resolving correctly, but the XML inside it is producing the wrong output. Open it in Machine Park, check the colour profile and offset values, save, and rerun the job. You don't need to touch the workflow.