Supporting Documents¶
You can attach your own material to a Project. Where it is used depends on how you label it, and getting that wrong quietly changes the result.
Why attach documents¶
The export tells SLIM what your integrations do. It says nothing about the world around them: what the business calls things, which schedule the work runs to, that the target database is about to change, or what has already been agreed with the customer.
Supporting Files are how you supply that. They are optional, and many Projects need none. Attach something when you know a fact that SLIM has no way of finding in the export, and that would change the outcome if it were missed.
Files can be attached when you create the Project, using the Supporting Files panel on the create form, or at any point afterwards from the Pipeline Generation Stage Page. Word, Excel, PowerPoint and PDF documents are converted to readable text as they are stored, so you can attach what you already have rather than rewriting it. Plain text, markdown, CSV, JSON and YAML files are read as they are.
Attachments belong to the Project rather than to the export, so they survive Replace Export.
Reference documents¶
A reference document describes the source workflow, or the world it runs in: scheduling, business context, a data dictionary, an analysis somebody has already written about the existing system.
Reference documents are available to the analysis Stages - Export Analysis and Integration Analysis - as context to read. SLIM is told explicitly that they describe the existing system and are not a design to conform to.
Nothing is lost to the later Stages by labeling a file this way. Whatever SLIM takes from a reference document goes into the analysis documents it writes, and Pipeline Generation works from those. The context still arrives; it arrives having been checked against the export first.
Design documents¶
A design document describes the target SnapLogic design: pipeline names, how the work is broken up, the project space to build in, mappings from source to target.
Design documents reach Pipeline Generation only. The analysis Stages are never told they exist.
That is deliberate, and it is the reason the two labels exist at all. A design document describes the future; the analysis Stages describe the present. If a design reached them, SLIM’s account of what your integrations do today would be shaped by what somebody intends to build tomorrow. The same care carries on inside Pipeline Generation: the Functional Representation is built from the analysis without seeing the design documents, and the design comes into play only when the SnapLogic pipelines are built from that representation.
Within Pipeline Generation, an attached design carries real authority. It decides structure - what the pipelines are called, how they are divided, where they are built. The analysis remains the authority on the detail a design does not go into, field-level mappings especially. Where the two genuinely disagree about structure, the design wins, and SLIM records the disagreement rather than quietly settling it.
Adding, re-labeling and removing attachments¶
On the create form, drag files onto the Supporting Files panel or click it to browse. Each file you add appears in a list with a SnapLogic design doc tick box beside it. The box starts unticked, so a file attached at creation is a reference document unless you say otherwise.
Afterwards, use the Design Docs panel on the Pipeline Generation Stage Page. Drop files there and click Add. The default is the other way round here: files added on this panel are design documents unless you move them.
Either way, the list below shows the two groups separately - SnapLogic design docs - used during Pipeline Generation only and Supporting files - available during analysis - so a mislabeled file is easy to spot. A group with nothing in it reads None.
To move a file between the groups, use the button on its row. The button is named after the group it would move the file to: Supporting on a design document, Design doc on a supporting file. The change applies to the next run.
To remove a file, use the delete icon on its row and confirm. That deletes the attachment only; your export and everything generated from it are untouched.
Two things to watch:
A file over 50 MB is skipped without a message. No more than 50 files are taken at once, either. If something you attached is not in the list afterwards, check its size before looking for another explanation.
A converted document says so. An Office document that converted successfully shows a second line under its name confirming it. If that line is missing, the conversion did not work: the file is stored, but SLIM cannot read it. Save a copy as text or markdown and attach that instead.
Both groups appear as folders in the Project Tree, so you can always confirm what a Project is actually carrying.
When a design has been signed off¶
Attaching even one design document changes what Pipeline Generation does, and it is worth knowing what you are turning on.
Before generating anything, SLIM reads the design documents and condenses them into a single summary, so every part of the work that follows is reading the same version of the design. Once the pipelines exist, it checks them against the design and writes a conformance report, CONFORMANCE_REPORT.md, alongside the generated pipelines in the Project Tree.
One limitation to know before you rely on that report: as things stand, it is only produced on an automatic run. If you press Generate Pipelines yourself in a step-by-step Project, the pipelines are generated but the design check does not run, and no button triggers it separately. This is a known gap that is expected to close. Until it does, check that the report is actually there before drawing conclusions from it, and see Choosing an Execution Mode for what the two modes commit you to.
That check is deliberately kept separate from the work it is checking. It does not take the generator’s own account of how well it did, and where it cannot confirm something it says so rather than giving it the benefit of the doubt. The report covers whether the pipeline names match, whether the work is divided as designed, whether the project space and shared libraries are right, how much of the source-to-target mapping is accounted for, what was deliberately left out, and whether the pipelines are valid.
Two rules decide what gets built, and the difference between them catches people out.
What a design excludes is left out. If a document says a piece of work is handled by another system, or is not being implemented in SnapLogic, or is out of scope, SLIM does not generate it - and records in the report that it was excluded, and why.
What a design does not mention is still built. Silence is not an exclusion. Work a design simply does not cover is generated from the source analysis as usual, and flagged in the report as having no design coverage, for somebody to review. So leaving something out of a design document is not a way to keep it out of the build. If you do not want it, say so.
One caution. SLIM cannot tell an approved design from a draft: a proposal attached as a design document is given exactly the authority an approved one would have. Attach designs that have been signed off, and keep working drafts out until they are.