Encrypted custom fields explained

Some of the data agents collect is sensitive: account numbers, identifiers, anything you would not want sitting in plain text in a database. Encrypted custom fields are the answer. They store the value scrambled with strong encryption so that even direct database access does not hand someone the raw data. Each one is still a Custom field on a list, attached to each Lead, but with an extra layer of protection. For the surrounding context, read the lists and leads guide.

What the encryption actually is

When you flag a field as encrypted, its values are stored using a 256-bit AES key that lives only on the web server, not in the database itself. That separation is the point: the encrypted blob and the key never sit in the same place. AES at this strength is a recognized, standards-approved scheme, which is why it is suitable as part of handling card and other regulated data. For a contact center that has to think about compliance, that is a meaningful piece of the puzzle.

flowchart LR
  A[Agent enters value] --> B[Web server encrypts with AES key]
  B --> C[Encrypted blob in database]
  C --> D[Agent opens lead]
  D --> E[Web server decrypts with key]
  E --> F[Plain value shown on form]

Which field types qualify

Not every field type can be encrypted. The ones that can are TEXT, HIDDEN, READONLY, HIDEBLOB, AREA, DATE, and TIME. That list covers most of the places sensitive data actually lands, from a free-text note to a stored date. There is also a related Field Show Hide option that masks part of a value, showing only set characters of a TEXT or READONLY field. That is useful when an agent needs to confirm the last few digits of something without ever seeing the whole thing. With a TEXT field, the system shows the masked value alongside a blank box, and if the agent types into that box the old value is overwritten when the call completes, so corrections are still possible without exposing the original.

The rules that bite

The timing rule above is the big one. Because you cannot flip an existing, populated field to encrypted from the interface, decide up front whether a field holds sensitive data. If you only realize later, a platform administrator has to convert it by hand, so it is far easier to plan it in from the start, before a single record exists. A good habit is to sketch out which fields are sensitive while you are still designing the list, then create those as encrypted from the very first save. One more limit worth flagging: encrypted values cannot be pulled into SCRIPT variables to show on the agent Script tab, which makes sense since the whole point is to keep them protected rather than echo them around the screen.

Encryption pairs naturally with a clean masking flow during payment moments, where an agent steps away from the data entirely. If that matters to you, look at how a PCI pause works alongside encrypted storage. Together they keep sensitive answers out of sight and out of the raw database.

Handling sensitive data well is far easier on your own dedicated box. VICIfast provisions one in under 40 seconds. See the pricing page to get started, and if you are new to lists, read what a VICIdial list is first.