Skip to main content

Documentation Index

Fetch the complete documentation index at: https://setup.cevro.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
What Are Player Fields?

Player fields are the data points available on each player—their name, email, VIP level, balance, and any custom fields you define. These fields power:
  • Automation rules — Route players based on their data
  • Player verification — Confirm player identity
  • AI personalization — The agent knows who they’re talking to

​
Types of Fields

TypeDescriptionExample
Built-inStandard fields on every player (cannot be modified)firstName, email, phone
CustomStatic fields you definepreferredLanguage, accountType
ComputedCalculated from back-office dataeligibleDepositSum, netBalance

​
Viewing Fields

Navigate to Settings → Player Fields to see all available fields. The fields list shows:
  • Type icon — Visual indicator of the field type
  • Field Name — The display label (or technical name if no label set)
  • Slug — The technical identifier used in code and rules
  • Actions — Edit button for editable fields
Fields are grouped into Custom (your defined fields) and Built-in (standard contact fields).
Fields with a lock icon have verification roles and cannot be edited on this page. To modify them, update the verification configuration in Settings.

​
Creating a Custom Field

1

Click New Field

Click the New Field dropdown button in the top right and select the field type:
  • Text — String values (languages, status codes)
  • Number — Numeric values (points, counts)
  • Boolean — True/false flags
  • Date — Timestamps
  • Computed — Calculated values (see below)
2

Enter Field Name

Enter a display name like “Total Deposits” or “VIP Level”.The system automatically generates the technical slug (e.g., total_deposits). The slug cannot be changed after creation.
3

Configure (Computed Only)

For computed fields, write your JavaScript expression. See the Computed Fields section below.
4

Save

Click Create. Your field is now available in rules and conditions.

​
Computed Fields

Computed fields let you combine data from multiple back-office tools into a single calculated value. Example: Calculate “eligible deposit sum” by finding deposits made after the last bonus gate.

​
Creating a Computed Field

1

Select Computed Type

Click New Field → Computed. A modal dialog opens.
2

Enter Field Name

Enter a display name (e.g., “Eligible Deposit Sum”). The slug is auto-generated.
3

Write the Expression

Write JavaScript code in the editor.Type @ to insert fields from your back-office tools. A searchable dropdown appears with all available fields. Selected fields appear as visual pills.
// Example: Sum deposits after last bonus gate
const lastGateDate = data.bonuses.find(b => b.type === 'gate')?.date;
const eligibleDeposits = data.deposits.filter(d =>
  new Date(d.date) > new Date(lastGateDate)
);
return eligibleDeposits.reduce((sum, d) => sum + d.amount, 0);
Data sources are automatically detected from your expression—no need to manually select them.
4

Test with Preview

Click Run to test your expression against sample data from your tools.Toggle between Computed (the result) and Raw Input (sample data from tools) to debug.The return type (Text, Number, Boolean, Date) is auto-detected when you run the preview.
5

Save

Click Create to save your computed field.
Computed fields must return a single value (not an array or object). If you need complex data, return a summary number or formatted string.

​
Editing Fields

Click the pencil icon on any editable field to modify it. You can change:
  • Display Label — Update the human-friendly name
  • For computed fields — Update the expression or return type
The field slug (technical identifier) and type cannot be changed after creation.

​
Deleting Fields

Field deletion is currently disabled to prevent breaking rules and segments that reference them. To remove a field, contact support. We’ll verify it’s not in use before removing it.

​
Verification Roles

Some fields have special roles in player authentication and show a lock icon:
RoleDescription
Help DeskAuto-filled from your help desk visitor payload
Security QuestionAsked during player verification
Lookup ResponsePopulated from your player lookup API
These fields cannot be edited on the Player Fields page. To modify their configuration:
  • Help desk fields — Settings → [Channel] → Help Desk Auth Config
  • Security questions — Settings → Agent Configuration → Player Authentication
  • Lookup fields — Settings → Agent Configuration → Player Lookup

​
Using Fields in Rules

Reference any field in automation rule conditions: 
IF vipLevel equals "platinum" THEN escalate
IF eligibleDepositSum >= 100 THEN qualify
See Automation Rules for details.

​
Using Fields in AI Procedures

In the AIP editor, type @ and pick a player field from the dropdown. The mention dropdown groups fields into four sections so you pick the right one:
SectionWhat’s in itWhen to use
Canonical FieldsBuilt-in contact fields (firstName, lastName, email, phone, address, externalId)Personalizing messages, identifying the player
BrandBrand name, player-facing name, slug, and API domainAny message where the brand appears — external notifications, live-agent handoff (HITL), player-facing copy
Custom FieldsStatic fields you definedWorkspace-specific data you attach to contacts
Computed FieldsCalculated from back-office toolsDerived signals like VIP tier, uncovered deposits
Each chip inserts a @attribute:<name> placeholder into the instructions. The agent resolves the placeholder before running the step — so by the time it drafts a response, it already knows the value. Example AIP instruction: 
The player's VIP tier is @attribute:vip_tier.
If they are "gold" or above, offer priority support.
Their current balance is @attribute:balance.

​
Brand fields — pick the right one

The Brand section exposes four chips. Which one you want depends on where the value ends up:
ChipResolves toWhen to use
Brand Name (brand.name)Human-readable brand name (e.g. “Gold”)External messages, live-agent handoff templates, player-facing copy — the default
Brand Player-Facing Name (brand.playerFacingName)Name as shown to players (falls back to brand.name when not set)Player-visible surfaces that may differ from the internal name
Brand Slug (brand.slug)URL-safe identifier (e.g. “gold-coast”)Links, deep references into brand-specific UI
Brand API Domain (brand.apiDomain)The brand’s API domainTechnical / debugging contexts only
There’s also a plain Brand chip in the Canonical section — it returns an internal ID used by automation rules for routing, not a human-readable name. Don’t put it in external messages; use Brand Name instead.

​
How it works

  1. Pick a field from the @ mention dropdown (or type @attribute:field_name directly).
  2. The agent resolves the placeholder automatically when processing the conversation — canonical and brand fields are available instantly; custom and computed fields are fetched as needed.
  3. The resolved value replaces the placeholder in the instructions.
This is useful when the agent needs to know player data to follow the right procedure — not just route based on it. For routing, use Automation Rules instead.
If a field value can’t be fetched (e.g., the player isn’t authenticated yet), the placeholder stays as-is. The agent will work with whatever information is available.

​
Best Practices

Instead of building complex rules, create a computed field that returns a simple true/false or category, then reference that in your rules.
Use clear names like “Total Deposits” instead of “td” or “field1”. The slug is auto-generated from your display name.
Use the preview feature to test your JavaScript with actual tool responses before saving. Check both the Computed result and Raw Input data.
Type @ in the expression editor to get a searchable list of all available fields from your tools—much easier than remembering field paths.

​
Troubleshooting

IssueSolution
Field not showing in rulesMake sure it’s saved and refresh the page
Can’t edit fieldIt has a verification role—update verification config instead
Computed value is wrongClick Run to test. Check Raw Input to see the data your expression receives
”Result must be scalar” errorYour computation returns an array or object. Return a single value instead
”A field with this name already exists”Choose a different field name—each must be unique
No fields available in @ dropdownYour tools need field catalogs configured
Need help? Computed fields can be tricky to set up. Contact support if you need assistance configuring your data model.