Introduction
Innoslate’s CSV Import Analyzer offers powerful features for rapidly building structured models from spreadsheet data. Beyond simply importing entities—such as requirements, test cases, and functions—the tool also enables users to automatically establish relationships between those entities through specific formatting in the CSV file. This functionality is especially valuable for engineers migrating data into Innoslate, though it is often overlooked or unrealized despite its limitless potential to automated the traceability process significantly.
This walkthrough focuses on how to define and import traceability relationships, such as “relates to", “allocated to,” or “satisfies” by including them as part of the CSV structure. Whether you're importing data from legacy documents or creating new structured content, this feature helps streamline the traceability process and save time.
To follow along and try out the import process mentioned in this walkthrough, click here to instantly download the UAV Performance Requirements .CSV File and import it into a new Innoslate project.
Walkthrough Use Case
Innoslate’s Import Analyzer is a powerful utility for importing data into a project from various structured formats, including .csv, .docx, .xml, and more. For many users, importing a Microsoft Excel CSV file provides a fast and flexible way to ingest large sets of entities—such as requirements, test cases, risks, or actions. In this walkthrough we will be adding an extra twist of creating relationships while doing a csv import.
On the Configure screen, users can control the following:
-
Document Type: Define whether the imported data becomes a Requirements Document, Project Management Plan, Concept of Operations Document, etc.
- Document Label: A schema-defined title for the document, such as “Requirements Document”, helps keep your model organized by type.
-
Default Class: This sets the fallback class for any entities that do not have a class explicitly defined in the CSV. In our case, it’s Requirement, meaning most entries will default to this unless overridden.
-
Attribute for Matching Existing Entities: This dropdown is crucial for relationship tracing. It tells the analyzer how to look up existing entities to either link to or avoid duplicating. We selected Number, which corresponds to the identifiers used in our CSV (e.g., R.1, PR.1.1).
-
Attribute for Matching Related Entities: This setting is what allows the importer to trace relationships. Again, we use Number so that if, for example, a requirement “causes” R.3, the importer knows to link to the entity with Number R.3.
Note: These two dropdowns should match the column in your CSV that uniquely identifies each entity you want to reference. If these values are incorrect or inconsistent with your data, relationship tracing will fail silently.
Structuring Relationships in the CSV
Before you reach the Customize phase of the import, it’s important to understand how relationships must be structured within the CSV file itself.
In the example shown above, each column labeled causes represents a separate relationship instance. If a requirement is meant to cause multiple risks, each one must occupy its own cell in a dedicated column.
Innoslate does not support combining values into a single cell with commas (e.g., R.1, R.2, R.3) to represent multiple relationships. Instead, each column must independently map to the same relationship type (in this case, causes). CSV import on Innoslate puts a great deal of importance on data conditioning. It is essential that users put a great amount of emphasis and importance on this step to ensure their data is conditioned properly to get mapped into Innoslate.
Import Customize Phase
The Customize phase is where the CSV import becomes powerful—and where mistakes can easily happen if you’re not careful. This is where you explicitly map each column from your CSV to the appropriate Innoslate attribute.
A common misconception is that you can list multiple target entities in one column using commas or semicolons (e.g., R.1, R.2, R.3). This will not work. The importer only reads one entity per cell, per column, for relationship formation. To link a single entity to multiple related entities, each relationship must have its own column, all mapped to the same relationship type—in this case, causes. Each of these is mapped to the causes attribute in Innoslate, instructing the importer to generate a relationship between PR.1.1 and each corresponding risk.
The mapping phase will automatically suggest attributes on Innoslate that have a similar names. In this example the attribute mapping will be pre-filled since the CSV columns mirror Innoslate attributes. In cases where it doesn't, the maps to attribute will be left empty and it is up to the user to allocate the mapping.
Relationship Type Dropdown Filtering
When mapping relationship columns in the Customize phase, you’ll encounter a dropdown for selecting the relationship type to apply to each column.
This dropdown is dynamically filtered by Innoslate based on the class of the entity being imported. For example, if you’re importing a Requirement, you’ll only see the relationships that a Requirement is allowed to form (such as causes, satisfies, allocated to, etc.).
This filtering approach reduces visual clutter by hiding irrelevant relationship types, prevents invalid configurations during import, and helps users align their CSV formatting with valid modeling logic.
Import Preview Phase
After setting up the mappings, the Preview screen provides a snapshot of what will be created or updated in your project. This is your last chance to review and catch issues before anything is committed to your Innoslate database.
You will find notable items for:
- Total Entities: In our case, 22 entities are being imported.
- Class Distribution: The preview shows how many entities fall under each class:
- New vs. Updated: Since this is a new import, all 22 entities are flagged as New. If you were importing updates to existing entities (matched by the “Number” field), they would show as Updated.
Although this import shows “No warnings reported”, this section is vital for catching unmapped fields, missing or duplicate identifiers, improper relationships, and entities being skipped due to invalid references
Notes: If any entity reference (like R.3) in a relationship column can’t be matched to another row’s Number field, the relationship will not be formed, and you’ll receive a warning. Always scroll through the list and check for any alerts.
Post-Import Validation
Once the import is complete, it’s time to verify that your relationships were formed correctly. Innoslate provides an intuitive way to do this using the Relationships tab within any entity.
In this example, we’ve opened the entity "PR.1.1 Billing Process", one of the performance requirements imported from the CSV. By clicking the Relationships tab, we can clearly see that this requirement has automatically established three “causes” relationships.
This confirms that our column-based relationship mappings were processed correctly during import. No manual linking was required after import.
Note: You can also click any of the linked entities (like R.1) to inspect their relationships in reverse—confirming full bidirectional traceability.
This view is useful not just for verification, but also for building on your model structure as you import large, interconnected datasets.
Visualizing Relationships using Traceability Matrix
This view displays entities on the Y-axis and their related entities—grouped by hierarchy, query, or relationship type—on the X-axis.
In this example:
-
The Y-axis lists imported Requirements (R.1, R.2, etc.).
-
The X-axis shows the causes relationship type pointing to corresponding Performance Requirements (PR.1.1, PR.1.2, etc.).
Each checkmark in the matrix confirms a relationship exists between the two entities.
Note: You can export this matrix for documentation or client review purposes, reinforcing the traceability rigor of your system model.
By combining structured import, entity-level review, and system-wide matrix views, you gain full confidence that your relationships were correctly formed—and can easily demonstrate that to stakeholders.
To continue learning about Modeling and Simulation, Click Here.
(Next Article: Design of Experiment (DOE) Walkthrough)