What pre-filling does

When an analyst opens a Bridge request from a Platform alert, the provided fields can already contain data from that alert, such as the sender's name or the payment reference. Each provided field in a Bridge template has a JSON configuration that decides what goes into it.

Pre-filled values can still be edited before the analyst clicks Send.

Configuration options

Fixed text with defaultValue

Use this when the field should always show the same text, whatever the alert.

{
  "defaultValue": "senderName"
}

Values from the alert with configurations

Use this when the field should show real data from the alert. Each rule in configurations has a fields list with the path to the data, for example transaction.attributes.senderName.

{
  "configurations": [
    {
      "fields": ["transaction.attributes.senderName"]
    }
  ]
}

A few things to know:

Everything in fields is read as a path, never as literal text.
If you list several paths, their values are joined with a space, so firstName and lastName give John Smith.
A rule can have conditions, so it only applies when a data point in the alert has a certain value. Example 2 below shows how.
If you have several rules, the first one that returns a value is used. If none does, the field falls back to defaultValue, or stays empty.

Paths you can use

Path	What it returns
`transaction.attributes.<attribute>`	An attribute of the alerted transaction, such as `senderName` or `reference`
`person.attributes.<attribute>`	An attribute of the alerted person, such as `firstName`
`transaction.id`, `person.id`	The ID of the alerted transaction or person
`fieldKey`	Screening alerts only. The name of the field that produced the match, such as `senderName`

🚨 Attribute names must match your data exactly, including upper and lower case. Check them in your schemas.

Examples

Both examples use a template with two provided fields: Field reference and Field value.

Example 1: the same data point every time

Field reference always shows senderName, and Field value shows the actual sender, such as John Smith.

Field reference

{
  "defaultValue": "senderName"
}

Field value

{
  "configurations": [
    {
      "fields": ["transaction.attributes.senderName"]
    }
  ]
}

Example 2: whichever field matched on a screening alert

Field reference shows the field that matched, and Field value shows its value. A match on receiverName gives receiverName and Jane Doe.

Field reference

{
  "configurations": [
    {
      "fields": ["fieldKey"]
    }
  ]
}

Field value has one rule per screened field. Only the rule whose condition matches the alert's fieldKey is used:

{
  "configurations": [
    {
      "fields": ["transaction.attributes.senderName"],
      "conditions": [
        { "type": "EQUALS", "fieldName": "fieldKey", "value": "senderName" }
      ]
    },
    {
      "fields": ["transaction.attributes.receiverName"],
      "conditions": [
        { "type": "EQUALS", "fieldName": "fieldKey", "value": "receiverName" }
      ]
    }
  ]
}

Add a rule for every field you screen. If an alert matches on a field that has no rule, Field value stays empty.

Where to configure it

In Bridge, go to Templates, open the template, select the provided field and click Edit as JSON.

Template editing is available to users with the Team lead role, once Salv has enabled it for your organisation. If you don't see Templates, contact your Salv account manager.

Troubleshooting

What you see	What to check
The field shows a value, such as John Smith, instead of a label, such as `senderName`	Text in `fields` is read as a path. For fixed text, use `defaultValue`.
The field works on screening alerts but is empty on monitoring alerts	The path starts with `entity.` or the rule has a `fieldKey` condition. Both only work on screening alerts. Use a `transaction.` or `person.` path without conditions, as in Example 1.
The field is always empty	Check the attribute name and case against your schema, and that the JSON is valid. Invalid JSON is ignored.

Pre-filling Bridge request fields from Platform alerts