Review Triggers
Generally available for enabled teams. A few trigger statements still require specific feature flags — see the table below.
Review Triggers automatically open reviews on companies in your portfolio when meaningful change happens. Instead of running a manual schedule, your team defines rules -- once a rule fires, Strise either opens a review or completes one automatically, depending on how the entity's risk class is configured.
Review Triggers are the core building block of perpetual KYB/KYC. Combine them with Monitoring for a reactive review workflow, or with time-based triggers for a periodic-review workflow.
How It Works
Each trigger is a statement about an entity: "a new flag was published", "beneficial ownership changed", "last review is older than 12 months", and so on. When the statement becomes true for an entity in your portfolio, the trigger fires. For changes in PEP and sanctions screening results, use Monitoring alerts instead.
What happens next depends on the entity's current risk class (Low, Medium, High). For each risk class you configure a default action:
| Action | Meaning |
|---|---|
MoveToManualReview | A new review is opened and assigned for manual review by your team. |
CompleteReview | The triggered event is recorded against the entity but no manual review is opened. Useful for low-risk entities where you want the audit trail but not the work. |
Defaults out of the box: High -> CompleteReview, Medium -> MoveToManualReview, Low -> CompleteReview. These can be overridden per team in settings.
Notifications
When a trigger fires on an entity, everyone assigned to that entity gets a Review Triggered notification naming the entity and the reasons the trigger fired. This works the same way for companies and for private persons.
An entity with no assignees produces no notification -- the trigger still fires and the work is still recorded, but nobody is told about it directly. Assign the entities you want your team to be alerted on.
Trigger Statements
A team can enable any number of trigger statements. Each statement sits in one of three buckets:
- Time-based -- evaluated by a daily cron job.
- Event-based -- evaluated as changes stream in from the Knowledge Graph.
- Scalar -- standalone values that are meaningful when combined with other triggers (e.g. a specific risk level).
Available Statements
| Statement | Kind | Requires | Description |
|---|---|---|---|
| Time Since Last Review | Time | -- | Fires once an entity's last review is older than the configured threshold (in months). For periodic re-review per risk class, set validity periods in Calculated Risk Settings instead. |
| Risk Assessment Value | Scalar | -- | Matches on the entity's audit risk level (Low/Medium/High). |
| Risk Level Value | Scalar | Calculated Risk | Matches on the entity's Calculated Risk class. |
| Credit Change | Event | Credit Data | Fires when Creditsafe credit data changes for the entity. |
| Financials Published | Event | -- | Fires when new financials are published. Can filter on specific financial fields and currency thresholds. |
| Flag Published | Event | -- | Fires when a new flag is attached to the entity. Filterable by flag kind. |
| Role Change | Event | -- | Fires when roles change on the entity. Filterable by specific role titles. |
| Beneficial Owner Change | Event | -- | Fires when beneficial ownership changes. |
Statements that require a feature toggle only appear in the UI once that toggle is enabled for your team.
Connect API
You can also trigger reviews programmatically through the Connect API. See reviewTriggerEventGenerate for the event-generation mutation and the API FAQ for how trigger statements behave in sandbox vs. production.
Best Practices
- Start narrow, not wide. Enable a couple of high-signal statements (Flag Published, Beneficial Owner Change) first, then expand once your team is used to the volume.
- Match the action to the risk class. Use
MoveToManualReviewfor Medium-risk entities where a human should look at every change; leaveCompleteReviewon Low-risk entities to keep the audit trail without workload. - Set validity periods as the safety net. Risk-class validity periods in Calculated Risk Settings re-review entities that have not generated any events; a bare "Time Since Last Review" trigger only adds value as a catch-all that applies regardless of risk class.
Last updated on