Bulk Edit and Bulk Add

Overview

Bulk Edit and Bulk Add are the spreadsheet route through Bulk Actions. You download the platform’s own view of the records, change it in a spreadsheet, and upload it back. The platform works out what changed, tests every row, and applies only what you approve.

This works the same way everywhere it appears:

Expert > Bulk Actions > Edit (or Add) on a customer, number or service page
Bulk Edit and Bulk Add on a settings list page, such as ticket types or locations
The checkbox selection page for a named action also offers “Download CSV” and “Upload CSV”, using the same conventions

You need Expert Mode, the Bulk Action Files permission, and edit (or add) permission for the records themselves.

Bulk Edit: Download, Change, Upload

The edit export

“Download CSV” produces a file with one row per record:

An id column and a revisionNumber column, which identify the record and protect against clashing edits
Every editable column, pre-filled with the current values

Values appear exactly as you would see them on the record’s form. Dropdown fields show their display names rather than internal codes, and yes/no fields show Yes or No. Dropdown names are matched without regard to letter case on upload, so a cell such as VOIP still selects a VoIP number type.

Editing the file

Change only what you want to change. The rules are simple, and worth remembering:

A blank cell clears that field. Blanking a cell is an instruction, not an omission.
A column you remove is left unchanged. Delete whole columns you are not updating; this is the safest way to work.
Unchanged rows are skipped. You do not need to trim rows you have not touched. The platform detects them and reports “No changes”.

You can also delete rows you do not want to process at all.

Uploading

Upload the file from the same page you downloaded it. The platform tests every row for real, inside a transaction it then rolls back, so the test catches everything a live save would: required fields, invalid values, unknown dropdown names and permission problems. Review the results, then apply. See Test, Then Apply for the lifecycle.

Bulk Add: Fill a Blank Template

“Download template” produces a header-only CSV of the columns you can set when creating a record. There is no id or revisionNumber column, and no parent column: records created under a customer, number or service are linked to it automatically.

Add one row per record to create. Blank cells take the field’s default value, the same defaults a new-record form would offer. Upload, test and apply as for an edit.

Rows without an id in an edit file are treated as adds too, so one file can update some records and create others.

CSV Conventions

These conventions apply to every bulk CSV, whichever page it came from.

Identification columns

id: identifies the record to change. Never edit this column.
revisionNumber: a safety check. If someone else changes the record between your download and your upload, the row fails with “Record changed since export” rather than silently overwriting their work. Remove the column if you deliberately want to override this check.

Header markers

A heading can carry a marker in brackets that tells the platform how to treat the column:

Marker	Meaning
(Information Only)	A context column added by an export, such as “Number (Information Only)”. It helps you decide which rows to keep and is ignored on upload, so you can leave it in place.
(Ignore)	Your own marker, added to a heading to exclude that column from the import. Useful where one file serves several purposes and you want a column left out without deleting it.
(Do Not Change)	Advisory. The column is still imported and its value still applies; the marker warns you that the cell is prefilled for a reason and editing it will break something.

(Do Not Change) is stripped before the heading is matched, so a column keeps working normally whether or not the marker is there.

Update Reason and Update Details columns

Add optional Update Reason and Update Details columns to any bulk CSV. A filled cell overrides the file-level audit reason or details for that row only. The reason must match one of your configured update reasons; an unknown name fails just that row.

Renaming: “Existing” and “Current” columns

Records in an upload are found by their identifying field, such as a number’s Number or a location’s name. That column normally cannot itself carry a new value, because it is busy finding the record.

To rename, use two columns: head the locating column with Existing or Current (for example “Existing Description” or “Description (Current)”), and add a plain column with the new value. The platform also accepts Old, Previous and Original as marker words. Edit exports that need this produce the “Current” column for you.

Finding a feature by its name

Every grid and export heads a feature’s name column Feature, because a feature is shown under its description, falling back to the name of the standard feature or feature type it was created from. A column headed Feature or Feature Name finds a feature the same way.

That column only locates the record, so a plain Description column beside it is free to carry a new value, and a blank cell clears the description. That is the shape a file needs when it is converting description-named features onto feature types.

A field of its own always wins: the locating behaviour applies only where the heading matches no field on the record. On an add file the heading is ignored with a warning, because there is nothing to locate.

An exact description match is taken first, and only where no description matches does the search widen to the displayed name. An ambiguous description therefore stays ambiguous rather than quietly widening into a different record.

Alternative column headings

A column can be headed with any of the names its field is known by, so a file you already have does not need re-heading before upload. This works on every upload route: the per-customer CSV, the cross-customer Bulk Action file and the Bulk Update file.

For example:

a drop or reinstate date column can be headed “Drop Date”, “Reinstate Date”, “Dropped / Reinstated Date”, “Dropped Date” or “Reinstated Date”
the customer column accepts “Account Number” as well as “Customer Account Number”
a number can be identified by “Telephone Number” or “CLI”

A column’s own proper heading always wins where both appear in the same file. Where an alternative name would fit two columns equally well, it is ignored rather than guessed at, so the file fails its test rather than importing into the wrong field. The reserved id, revisionNumber, Update Reason and Update Details headings are never taken by an alternative.

Downloads and templates always carry the platform’s own heading.

Matching telephone numbers

Number and Alternate CDR Number columns are matched with spaces and dashes ignored on both sides, so a cell written 01234567890 finds a number stored 01234 567890. This governs bulk file lookups only: alternate CDR numbers are matched exactly everywhere else, including call rating and the number forms.

Bulk Action and Bulk Update files also recognise the spreadsheet protection prefix saved when the file was uploaded. For example, _01234567890 matches 01234567890 when _ is the configured prefix. Keep the exported prefix when editing numbers in a spreadsheet so leading zeroes survive.

Lookup values

Where a field takes a value from a list, such as a number type or a status, the value is matched without regard to letter case, so VOIP selects an existing VoIP number type. A value matching more than one entry fails its row for correction rather than picking one.

Multiple-choice fields

A field that holds several values, such as a call type’s custom groups, appears as a single cell of comma-separated display names, quoted as needed. Edit the list in place: the platform resolves each name on upload. A blank cell clears the whole list.

Dates

UK-format dates (dd/mm/yyyy, and variants with . or - separators) are accepted and converted automatically. ISO dates (yyyy-mm-dd) also work. Two-digit years read as 20xx.

Per-row values on named actions

Named-action CSVs include the action form’s fields as columns, for example “Drop Date”. A blank cell uses the value from the shared form; a filled cell overrides it for that row. This lets one file drop different numbers on different dates.

Troubleshooting Row Failures

Each failed row shows a message in the results grid. The common ones:

Message	What it means
”Record changed since export”	The record was edited after you downloaded the file. Re-download, re-apply your change, and upload again.
”Record does not belong to this customer”	The row’s id belongs to a different customer than the file was launched from. Check the id column has not been edited.
”Unknown value for [field]“	A dropdown cell does not match any existing name. Check spelling against the record’s form.
”Ambiguous value for [field]“	A name matches more than one record. Use a more specific value.
”Permission denied”	You do not have permission for that record, or the record is no longer eligible for the action.
”Record not found”	The id no longer exists, usually because the record was deleted after export.
”Add would fail - check required fields”	An add row is missing a required value. The message usually names the field.
”No changes” (Skipped)	Not a failure. The row’s values already match the record, so nothing was saved.

A failed row never blocks the rest of the file. Fix the flagged rows and re-upload, or apply the passing rows and deal with the failures separately.

Bulk Actions: the overview, entry points and lifecycle
Bulk Update and Bulk Action Lists: for files from other systems, matched by name rather than id
Bulk Rate Updates: the rate-sheet version of this workflow for tariff and fixed fee tariff rates
Update Rules Reference: the rules language for files that need extra handling
User Activity Configuration: managing the update reasons used in audit entries