Adding one tag by hand is fine, but nobody wants to click through a wizard three hundred times to bring in a full flow computer or a whole new site. A CSV import turns tag creation from a per-tag chore into a spreadsheet exercise: you lay out every tag as a row, with columns for its name, address, type, scaling, units, and alarms, and the SCADA system builds them all in one pass. The power of this approach is also its danger, because a mistake made once in a spreadsheet gets repeated across every row, and importing hundreds of tags with a systematic error is a fast way to make a large mess. The skill, then, is not just building the file but importing it safely: getting the columns right, avoiding the duplicate and naming collisions that break an import, validating before you commit, and knowing how to undo a bad import cleanly. This guide covers the whole bulk workflow as the scale-up counterpart to configuring a single tag.
How to import tags from a CSV in one line: To import tags from a CSV in SCADA, build a spreadsheet where each row is one tag and the columns carry everything the system needs, name, device, address, data type, scaling, engineering units, description, and any alarm limits, matching the exact column names the import expects. Before committing, run the import in a validate or preview mode so it checks for missing fields, bad addresses, and duplicate or colliding names, and fix the flagged rows in the spreadsheet rather than in the system. Only after a clean validation do you commit, and you keep the file and a pre-import backup so you can roll back cleanly if the import turns out wrong.
A tag import file is just a table where every row defines one tag and every column supplies one property of that tag, so the first job is to know which columns the import expects and to name them exactly as required. The essential columns mirror the decisions you would make adding a tag by hand: the tag name, the device or connection it reads from, the address or register in that device, the data type, the scaling that converts raw to engineering units, the engineering units label, and a description. A useful file also carries alarm columns, the HI, LO, and more urgent limits, and any priority, so that alarms are created along with the tags in the same pass rather than as a second manual round.
The most reliable way to get the columns right is to start from a template rather than a blank sheet. Most SCADA tools can export the existing tags to a CSV, or provide a sample import file, and that export shows you the exact column headers and formats the import will accept. Starting from an export of a few correctly configured tags means the structure is guaranteed to match, and you fill in the rest by copying the pattern of the working rows. Building the header row by guessing is where imports fail before they even start, because a column named slightly wrong is simply ignored and its data silently lost, so the tags import missing their units or their scaling.
The spreadsheet is also where the real productivity of bulk import lives, because a spreadsheet is far better than a configuration screen at generating regular data. When you are importing two hundred nearly identical tags, a bank of flow meters, a row of identical wells, the address usually increments in a predictable pattern and the names follow a convention, and a spreadsheet formula can generate both automatically, filling column after column with the incrementing addresses and consistently formatted names in seconds. This is exactly the kind of repetitive, patterned work that is miserable by hand and trivial in a spreadsheet, which is a large part of why bulk import exists in the first place. Getting the pattern right once and filling it down is the core move.
The error that most often derails a tag import is a naming collision, where the file tries to create a tag with a name that already exists or two rows in the file share the same name. Tag names usually have to be unique, so a collision forces the system to reject the row, overwrite the existing tag, or duplicate it, none of which is what you want by accident. Collisions creep in easily when you copy rows and forget to update the name, or when a spreadsheet naming formula produces a duplicate for two similar points. Scanning the name column for duplicates in the spreadsheet before you even attempt the import, which a spreadsheet can do trivially, catches most of these while they are still just a cell to fix.
The single most important safety step is to validate before you commit, and any decent import tool offers a way to check the file without actually creating anything. This validate or preview pass reads every row and reports the problems, a missing required field, an address that does not fit the device, a data type it does not recognize, a duplicate name, a scaling value in the wrong format, and lists exactly which rows are wrong. The discipline is to run this pass, read the report, and fix every flagged row in the spreadsheet, then validate again, repeating until the validation comes back clean. Fixing problems in the source file rather than in the system after import keeps the spreadsheet as the single accurate record of what was imported.
Validating first is what separates a controlled bulk import from a chaotic one, because it moves the errors from a live, half-built system back into a spreadsheet where they are cheap to correct. Committing an unvalidated file means discovering the problems as half your tags come in broken and half fail, leaving you to untangle which of hundreds of tags imported correctly and which did not. A clean validation before commit means that when you finally do commit, you already know it will succeed, so the actual import is anticlimactic, which is exactly what you want a bulk operation to be. The few minutes spent iterating on validation save hours of cleanup, and they are the habit that makes bulk import trustworthy at scale.
Even with validation, an import can turn out wrong in ways validation cannot catch, tags that import cleanly but point at the wrong addresses because the source data was wrong, or a scaling convention that was misunderstood across the whole file. So before running any real bulk import, you take a backup of the configuration, so that whatever the import does, you have a known-good state to return to. Rolling back is then simply restoring that pre-import backup, which cleanly removes everything the import added and reverts anything it changed, as if the import never happened. This safety net is what makes it reasonable to attempt a large import at all, because the worst case is a restore rather than a manual hunt for hundreds of wrong tags.
It is worth knowing exactly how your tool handles rollback before you need it, because tools differ. Some let you undo an import as a single operation, some group an import so you can delete all the tags it created at once, and some offer only a full configuration restore. If none of those is available, the fallback is that the spreadsheet itself is your rollback plan: because you have the exact list of names you imported, you can build a targeted deletion or correction from the same file. Either way, the principle holds that you should know how you will undo an import before you run it, and having both a backup and the source file gives you two independent ways to recover.
Bulk CSV import is also the natural tool for migrating an existing system, and this is where it shines when moving to a cloud platform. When onboarding a site to a cloud SCADA platform such as Merobix, exporting the existing tag list from an old system into a spreadsheet, cleaning and reshaping the columns to match the new import format, and importing the whole site at once is dramatically faster and less error-prone than rebuilding every tag by hand. The spreadsheet becomes both the migration vehicle and a clean, auditable record of exactly what the site's tag database contains, which is valuable long after the import is done. For a fleet of sites this scales beautifully, since a well-structured spreadsheet for one site becomes the template for the next, turning what could be weeks of manual configuration into a repeatable import you validate and commit per site.
Each row is one tag, and the columns mirror what you would set by hand: the tag name, the device or connection, the address or register, the data type, the scaling, the engineering units, and a description, plus alarm limits and priority if you want alarms created in the same pass. The safest way to get the exact headers and formats right is to start from an export of a few correctly configured tags rather than a blank sheet, because a mis-named column is silently ignored and its data lost.
Naming collisions, where the file uses a name that already exists or two rows share the same name, are the most common cause of failed imports because tag names usually must be unique. They creep in when you copy rows without updating the name or when a naming formula produces a duplicate. Scan the name column for duplicates in the spreadsheet before importing, which a spreadsheet does trivially, and run the tool's validate pass, which will also flag any name that collides with an existing tag.
Take a configuration backup before running any real bulk import, so that rolling back is simply restoring that pre-import state, which cleanly removes everything the import added. Know in advance how your specific tool handles this, since some offer a single undo of an import, some let you delete all tags an import created at once, and some offer only a full restore. The spreadsheet is also a rollback aid, because it holds the exact list of names imported, from which you can build a targeted deletion.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.