Skip to main content
Read this before you rely on it. A field type you describe is detected in the Try it test box on the Sensitive data page, so you can see exactly what it would match and what your policy would do with it.It is not yet applied to live ingestion or to search. Content flowing through Synap today is matched against the shipped field types only. Describing your own field type records it, shows you what it would catch, and prepares the policy, but it does not yet change what happens to your traffic.If you need a custom format protected in production now, talk to us at [email protected] rather than assuming the definition is live.

​
When you need one

Synap ships detection for formats that are common across products: email addresses, phone numbers, card numbers, government identifiers, IP addresses, API keys. It does not ship detection for formats that are specific to your business. An asset tag, a policy number, an internal order id, a claim reference: these identify a person or a case in your product, they appear all over your content, and nobody outside your company would recognise the shape. That is what this is for.

​
Describing one

1

Open the tab

In the Dashboard, go to Sensitive data, then the Your own field types tab.
2

Name it

Give it the name your team already uses, in plain words: “Asset tag”, “Policy number”, “Claim reference”. The name is what appears in your findings list, in the test box, and in your audit trail, so it should read like something a person would say out loud.Names must be unique and cannot reuse the name of a field type Synap already ships.
3

Pick a category

Every field type sits in one of the eleven categories, and the category is what carries the setting. Picking the category is the decision that matters, so see the guidance below.You can move it to a different category later, and the setting follows it.
4

Give real examples

Paste two or three real examples, one per line:
Synap builds a pattern from the shape of what you give it: which positions are letters, which are digits, how long each run is, and where the separators sit. Three asset tags produce a pattern that matches asset tags.
5

Save it, then check it

Save, then open the Try it tab and paste text containing one of your identifiers. A match appears badged as your field type, with what your policy would do with it at each destination.If the tab shows your field type as inactive with “not detected yet, needs examples”, no usable pattern could be built from what you gave. Add more examples, or examples that are more alike. Synap will not fall back to a pattern that matches everything, because a rule that fires on all text buries you in false alarms while looking like the feature working.

​
Writing examples that work

The pattern is built from structure, not from meaning. That has three practical consequences. Cover every shape your identifier takes. If asset tags are sometimes AST-00123 and sometimes AST-00123-R, give at least one of each. Each distinct shape you provide becomes one thing the pattern will match; a shape you never showed will never be found. Give examples of the same thing, not a grab bag. Three unrelated strings produce a pattern that matches those three shapes and nothing else, which is honest but not useful. Three genuine examples of one format produce a pattern for that format. The more distinctive the shape, the better it works. AST-00123 has a literal prefix and a fixed digit count, so it matches almost nothing else. A bare six-digit number matches every six-digit number in your content, including quantities, order totals, and years in a row. If your identifier is a bare number, expect false alarms, and check the test box before you protect it. A few things to know:
  • Up to 20 examples. Examples longer than 128 characters are ignored.
  • Examples are used to build the pattern and are never returned by the API. The dashboard shows how many you gave, not what they were.
  • Changing the examples means updating the field type; the pattern is rebuilt from what you save.

​
Picking the category

The category decides the setting, so pick by asking “what should happen to this value?” rather than “what is it technically?”. Two rules of thumb:
  • When it is close, pick the stricter one. A category is a default you can override per field type later, and starting stricter costs you nothing visible: a value that is protected and revealed straight back to your app reads identically to one that was never protected.
  • Do not invent a category for a field type that only matters to you. If an order id genuinely needs different handling from everything else in Formal Identity, put it there and set a per-field-type exception on the advanced view.
Secrets is not the floor. Putting a field type in Secrets applies whatever setting you gave that category. The floor is a fixed list of seven shipped field types that are never kept for anyone, and a field type you define cannot join it. If you have a secret format that must never be stored, set the category to Do not store it.

​
What happens next

Once your field type is detected, it behaves like any shipped one. It appears in your findings list with counts, it appears in the test box, it takes the setting from its category unless you set an exception, and if you protect it, it gets an alias like everything else. Aliases for your own field types are prefixed CUSTOM. Removing a field type stops it from being detected going forward. Memories already written are unaffected, and any placeholders already in them keep resolving.

​
Next steps

Sensitive Data Protection

The categories, the settings, and what detection can and cannot do.

Configure it

The findings list, the test box, and approving a policy.