Bulk Update and Bulk Action Lists

Overview

Bulk Update processes files that did not come from the platform: a supplier’s spreadsheet, a carrier’s port-out list, or a report that spans many customers. These files identify records by names, not platform ids, so the platform matches each row to the right record for you.

It reads the file’s column headers, recognises them against the platform’s own field names, and looks each row up through the customer hierarchy: find the customer, then the number within that customer, then the feature within that number. You do not need to add ids or restructure the file.

Two flows share this matching engine, both launched from the View / Edit Bulk Action Files page (see Bulk Actions):

New Bulk Update: generic edit or add from an arbitrary file
New Bulk Action: run a named action, such as Drop, over an uploaded list of records that may span several customers

Both need Expert Mode and the Bulk Action Files permission.

New Bulk Update

Go to the View / Edit Bulk Action Files page and choose New Bulk Update from the Add menu
Pick the Object type (what kind of record the file describes) and the Action (Bulk Edit or Bulk Add)
Choose your Data file (CSV or Excel, up to 100 MB)
Set the Update reason and Details for the audit trail
Click “Upload”

The platform reads the file in the background, matches every row to its records, and then tests the result automatically. The file page shows live progress, then the per-row results: which rows resolved, which could not be matched, and which were skipped. Nothing changes until you click “Apply”.

How rows are matched

Headers are recognised by name. Each column heading is matched against the platform’s field names and their common aliases, the same names used by bulk import. Unrecognised columns are reported and ignored. Columns suffixed “(Information Only)” are skipped silently.
Names are looked up in context. A customer column (account number or company name) scopes the row. A number is then matched within that customer, and a feature within that number or service. This means two customers can have features with the same name without any ambiguity.
ID columns win. If the file came from a platform export it may carry id columns such as “Feature ID” or “Customer ID”. These identify records directly and take precedence over name matching. When a record is identified by its id, its name column becomes an ordinary update column, so platform exports can be edited and re-uploaded directly, including renames.
Renames use marker columns. To change a record’s own identifying value, head the column that finds it with Existing or Current (“Existing Description”) and put the new value in a plain column. See the CSV conventions.
Ambiguous matches fail safely. If a name matches more than one record, the row fails rather than guessing. Adding a narrowing column, such as “Site” for numbers, lets the platform tell them apart. The row’s error names the columns that would help.
Update Reason and Update Details columns set the audit reason and details for individual rows, as on any bulk CSV.

Reviewing the generation log

After processing, the file’s log summarises the run:

Processed 1,204 row(s): 1,187 resolved, 9 unresolved, 8 skipped.
  Rows skipped: 6 empty rows (lines 2, 15, ...), 2 totals row (lines 1203, 1204).

Unresolved rows appear in the results grid with the reason they could not be matched, so you can fix them in the file or handle them by hand. Skipped rows, such as blank lines or a totals footer, are counted in the log with their line numbers. Rules can also flag rows for a second look without skipping them; these are counted the same way under “Rows flagged”.

Fixing and re-running

A Bulk Update file is a workspace until it is applied:

Re-upload replaces the data file on the same job, keeping the settings and audit details
Edit lets you correct the object type or action, or adjust the rules; the platform re-generates and re-tests automatically
Test re-runs the matching and test from scratch at any time

If the file cannot be understood at all, for example no column identifies the records, processing stops with guidance in the log naming the columns it needs.

Carrier rate files

Bulk Update also handles carrier rate files for call tariffs and fixed fee tariffs: a file with a “Tariff Name” column routes each row to the named tariff, and the rate within it is matched by call type, call time and start date. Rate files have their own guide covering based-upon inheritance and dated rate versions: Bulk Rate Updates.

New Bulk Action

Use this to run a named action over a list of records from a file, across as many customers as the list covers. A typical example is a carrier’s list of numbers porting away, which you want to drop.

Choose New Bulk Action from the Bulk Action Files page’s Add menu
Pick the Object type and Action, then click “Continue”
Fill in the action’s form; these values apply to every row unless a row overrides them
Click “Download a template” if you need the expected columns, or upload your own file with matching headers
Upload, review the test results, and apply

The template includes a customer column, the identifying column (for example “Number”), any narrowing columns, a column per action form field for per-row overrides, and the Update Reason and Details columns. Rows that cannot be matched, or whose record is not eligible for the action, are reported when you test; nothing changes until you apply.

This flow is also where the bulk annual price increase actions live for standard features, tariffs and fixed fee tariffs. See Price Increases for what the increase actions do.

When a File Needs Rules

Most files need no configuration at all. Automatic recognition handles any file whose headers match the platform’s field names or aliases. You only need rules when the file itself is awkward:

Headers with names the platform does not recognise
Values that need reshaping, such as “12 Minutes” where the platform wants seconds
Junk rows to skip, such as report footers or subtotals
Files without headers, fixed-width files, or unusual encodings

Rules are a short piece of YAML (a simple, indented text format) pasted into the Advanced - rules override box on the New Bulk Update form. They add to the automatic recognition rather than replacing it: you describe only the awkward parts, and the defaults handle the rest.

Small examples

Skip a totals row at the bottom of a report:

rowRules:
  endProcessing:
    when:
      - {field: 'Account Number', equals: ['Total']}

Clean up the values in a recognised column, stripping currency symbols:

fields:
  feature.serviceCharge:
    transforms:
      - remove: currency symbols

Read an American-format date column correctly (the platform assumes UK day-first dates):

fields:
  feature.startDate:
    transforms:
      - date: '%m/%d/%Y'

Map a column whose heading the platform does not recognise by naming the field and the heading:

fields:
  feature.site:
    header: 'Location'

Skip rows based on a column that is not part of the update. A temp. field can read any column, including “(Information Only)” ones, for use in rules without changing anything:

fields:
  temp.contractEnd:
    header: 'Contract End Date (Information Only)'
    aka: 'Contract End Date'
rowRules:
  skip:
    - name: Still in contract
      when:
        - {field: 'Contract End Date', present: true}

Flag doubtful rows for review instead of skipping them. Flagged rows are still processed, but the log counts them so you can check them before you apply:

rowRules:
  warn:
    - name: Unusually large charge
      when:
        - {field: 'Recurring Charge', atLeast: 100}

The Update Rules Reference covers the whole language.

Validating rules

The “Validate rules” button next to the rules box checks your YAML instantly, without uploading anything. Errors name the exact place in the rules that is wrong. The rules language is strict on purpose: an unknown setting is an error, never silently ignored, so a typo cannot quietly disable part of your rules.

Saved rulesets

If you process the same supplier’s file regularly, your platform administrator can save its rules as a named ruleset. Saved rulesets appear in a Saved ruleset dropdown on the New Bulk Update form for that object type, and selecting one fills in the rules box. Ask support to set one up once you have a working ruleset.

Getting an AI Assistant to Write Your Rules

You do not need to learn the rules language. The Update Rules Reference is written so that an AI assistant, such as Claude or ChatGPT, can author correct rules for you:

Give your assistant the reference’s plain-Markdown address, https://documentation.billingplatform.uk/bulk-operations/rules-reference/agents.md. If it cannot fetch pages, download the file from that address and attach it to the conversation instead
Describe your file: paste its header row and two or three example data rows, and say what you want each column to do
Say what kind of records you are updating, and mention anything odd, such as footer rows or unusual date formats
Paste the assistant’s YAML into the rules box and click “Validate rules”
If validation reports an error, paste the error back to the assistant and ask it to fix the rules

The test step remains your safety net. However the rules were written, no row changes anything until you have reviewed the test results and applied the file.

Bulk Actions: the overview and lifecycle shared by every bulk flow
Bulk Edit and Bulk Add: CSV conventions shared with these flows
Update Rules Reference: the complete rules language, written for AI assistants
CDR Processing Rules: the same rules language applied to carrier call data files
Bulk Import Files: the older import facility, still available