Operator guideEN

Activity Tag Rules / Applications

Read-only recent recorded application rows inside rule detail, including user ID, tag outcome, timestamp, and captured activity payload.

How to use this guide

Start with the main guide

Follow the explanation and examples first. Extra definitions and formulas are available below when you need them.

What this section shows

This relation section shows the latest recorded application rows for one activity tag rule. Operators can confirm that a live webhook event reached an existing user after the rule's live condition check, then added a tag, removed a tag, or found that the requested tag change was unnecessary.

How to read it

  • User ID is the player/user identifier stored on the audit row.
  • Action shows the recorded outcome: added, removed, or skipped. A recorded skipped row means the tag was already present for an add rule or already absent for a remove rule.
  • Date is the application timestamp formatted for the table.
  • Activity Data is the captured activity payload rendered as JSON text.

Main states

  • Loading appears while the recent application slice is being requested.
  • A table appears when at least one application row is returned.
  • An informational empty state appears when no application rows are available for the rule.

Important caveats

  • The detail screen requests only the latest ten application rows.
  • This section is read-only on the current surface.
  • This is not a complete activity-event audit. The writer creates no row when rule conditions fail, the user is not found, or processing errors before application persistence.
  • The current live evaluator supports minCount, maxCount, minAmount, maxAmount, and timeFrame, not the condition keys offered by the CRM form.
  • Manual Run does not create application rows; these rows come from live activity-event processing.
  • Activity Data is shown as raw JSON text from the audit record.
  • The source response includes pagination metadata, but the verified section does not render pagination controls.
  • The source response can include user details for each row, but the verified table renders only the numeric User ID.
  • The relation hook's failed read can appear as the same empty state as a successful zero-row response because the component has no dedicated error presentation.

Relation rendering, read behavior, live webhook writer, skipped semantics, and application-row fields have been traced. No workspace-settings or casino-side semantic dependency was found.

More details

Definitions and formulas

Open only the section you need. The relevant section opens automatically when you request help for a specific item on screen.

Calculations6 topicsOpen details

Recent applications slice

Logic
The relation read is filtered by the current activity tag rule ID., The page requests a limit of ten rows., The source orders application rows by creation time descending., The source returns pagination metadata, but the verified section does not render relation pagination controls., The returned rows are not a complete event audit because the writer omits condition-failed and missing-user outcomes.

Action chip mapping

Logic
Action `added` renders as a success chip., Action `removed` renders as an error chip., Action `skipped` renders as the default chip style.

Date formatting

Logic
Application creation time is parsed and formatted as `yyyy-MM-dd HH:mm:ss`., Missing dates render as `N/A`., Parse failures fall back to the raw returned value.

Activity data rendering

Logic
Populated activity data is rendered as JSON text., Missing activity data renders as `N/A`., The verified section does not expand or redact individual JSON keys.

Empty and error state caveat

Logic
The component shows a loading text while the relation read is in progress., When no rows are available, the component shows an informational empty state., The verified component does not render a separate relation error message, so read failures can look similar to an empty relation.

Application writer boundary

Logic
The signature-validated activity webhook invokes live rule processing for one user and activity event., A failed condition check returns a skipped result without creating an application row., A missing user returns a skipped result without creating an application row., For an existing user after conditions pass, added, removed, or no-change skipped is persisted as one application row., Manual Run does not invoke this writer path.
Columns6 topicsOpen details

Row ID

Stable audit-row identifier used as the table row key; it is not shown as a visible column.

Visual Type
hidden-row-key

Rule ID

Links the application row back to the current activity tag rule; it is used by backend filtering and not shown as a visible column.

Visual Type
hidden-relation-key

User ID

Player identifier for the audited application row.

Visual Type
grid-column

Action

Whether the live rule added a tag, removed a tag, or found no tag mutation was needed after reaching an existing user.

Visual Type
badge
Enum Values
added, removed, skipped
Display
Added: success chip | Removed: error chip | Skipped: default chip
Caveats
A recorded skipped row means add found the tag already present or remove found it already absent., Condition-failed and missing-user outcomes do not create rows and therefore are not represented by this value.

Date

Timestamp when the application row was recorded.

Visual Type
datetime
Display Format
yyyy-MM-dd HH:mm:ss
Fallback
Raw value when parsing fails.

Activity Data

Raw activity payload snapshot saved with the audit row.

Visual Type
json-preview
Display
Populated: JSON text | Empty: N/A
More help

Related pages

Activity Tag Rules

Operator documentation for activity-driven tag automation rules, including list, create, edit, detail inspection, and recent application history.

Activity Tag Rules / Create

Create flow for a new activity tag rule, including optional clone-from-existing behavior, transaction condition testing, and one-or-two-rule save behavior.

Activity Tag Rules / Detail

Rule inspection page with stored identity, conditions, timestamps, impact estimate, run action, delete action, and recent application history.

Activity Tag Rules / Edit

Edit flow for one stored rule or an existing grouped add/remove pair, including grouped form rebuild, condition testing, and update-only save behavior.

Activity Tag Rules / List

Main inventory for activity-driven tag rules, with search, activity and status filters, grouped rows, clone, edit, and run actions.

Reporting / Change Notification Detail

Detail page for one audit entry, including actor metadata, description, and before/after comparison views.