POST recording filename variables explained (POSTVLC, POSTSTATUS)

Most filename variables resolve the moment a call ends, but some values are not known until after the agent finishes wrapping up. The POST recording variables solve that. They rename the recording file once the call is fully done, replacing each POST token with a value pulled from a default field. There are four of them: POSTVLC, POSTSP, POSTARRD3, and POSTSTATUS.

What makes POST variables different

The standard variables, things like CAMPAIGN, CUSTPHONE, and FULLDATE, are filled in when the recording is created. The POST variables run a second pass. After the call has finished, they alter the recording file name and swap the POST token for the value from the relevant default field. POSTSTATUS, for example, lets you stamp the final call Disposition into the filename, which you cannot do up front because the agent has not chosen it yet. That is the whole reason POST processing exists.

Because they run later, POST variables only work if your dialers have POST recording processing enabled. Without it, the tokens will not resolve. With it, you can append a final-status suffix to any name you have already built from the standard set. The values come from the default fields tied to each token, so the data has to exist on the call for the rename to produce something meaningful. POSTVLC, POSTSP, and POSTARRD3 each map to their own field, and POSTSTATUS maps to the call's final status.

The two-stage rename

flowchart TD
  A[Recording starts] --> B[Build name from standard variables]
  B --> C[File saved with initial name]
  C --> D[Agent dispositions the call]
  D --> E{POST processing enabled}
  E -->|No| F[Name stays as is]
  E -->|Yes| G[Replace POSTSTATUS and friends]
  G --> H[File renamed with final values]

Think of it as two stages. Stage one names the file from values known at save time. Stage two, only if POST processing is on, rewrites the name once the post-call data exists. POSTSTATUS carries the final status, while POSTVLC, POSTSP, and POSTARRD3 pull their own values from their respective default fields. You combine them with the standard variables, so a template like CAMPAIGN_TINYDATE_CUSTPHONE_POSTSTATUS gives you a file whose name ends in the outcome of the call.

This is genuinely useful for sorting. If every filename ends in its final Status (lead status) code, a QC reviewer can pull all the sale dispositions or all the not-interested calls without touching the database. Pair it with a Disposition scheme your team already uses and the recording archive becomes self-describing.

Things to watch

The same 90-character cap applies to the finished name, and POST suffixes add length on top of whatever the standard variables already produced, so leave headroom. Also remember these tokens stay literal until POST processing runs; if you see filenames with the word POSTSTATUS still in them, that processing is not enabled on the dialer. And because the rename happens after the call, do not expect the final name to appear the instant the recording stops. It settles a moment later, after the agent has dispositioned the call and the post-call values are available. If any tooling watches the recording folder and acts on filenames, build it to expect that brief gap rather than the name being final the second the file is written.

For the standard variables that form the first stage of the name, see every Campaign Rec Filename variable, and for the wider setup see our call recording guide.

POST processing is the kind of detail that is easy to misconfigure on a self-managed box. If you would rather it just work, look at our pricing and we will handle the plumbing.

These variables are set per Campaign, so each one names its files its own way.