Skip to main content
Violations are records of detected rule breaches. This guide covers the complete violation management system, including creation, status tracking, and delivery to brands.

​
What is a violation?

A violation represents a detected event that breached a configured rule. For example:
  • A person detected in a restricted area
  • Smoking detected in a no-smoking zone
  • Equipment left unattended
  • Safety gear not worn

​
Violation data model

A violation record contains the following fields:
FieldTypeDescription
idstringUnique identifier
branch_rule_idstringRule that triggered the violation
started_atstringWhen the violation started
ended_atstringWhen the violation ended
main_attachmentstring[]Video clips or full images
sub_attachmentstring[]Detection crops
timestampstringCreation timestamp
notestringAdditional context
statusstringCurrent status
created_atstringDatabase creation time
updated_atstringLast update time

​
Violation status workflow

Violations progress through several statuses as they’re processed and delivered:
StatusArabicDescription
Created-Violation record created, attachments uploaded
EscalatedتأكيدReady for brand delivery
UploadedرفعتDelivered to brand’s system
Closed-Violation resolved
Flow: Created → Escalated → Uploaded → Closed

​
Creating violations

Violations are created by the create_violation business action. This action:
  1. Collects attachments from all previous detection actions
  2. Uploads attachments to Supabase storage
  3. Calls the insert-violation edge function to create the record
  4. Returns the violation IDs for subsequent actions
For detailed information, see the create violation documentation.

​
Attachment types

Purpose: Full context of the violationCommon formats:
  • Video clips (.mp4, .webm) - typically 10-30 seconds
  • Full-frame images (.jpg, .png)
Storage: Uploaded to Supabase violations bucket

​
Delivery methods

RES supports multiple delivery channels for violations:

​
1. Webhook delivery

Send violation data to an external API endpoint. The webhook payload includes:
FieldDescription
violation_idUnique identifier
branch_rule_idRule that triggered the violation
timestampWhen the violation occurred
main_attachmentArray of video/image URLs
sub_attachmentArray of detection crop URLs
rule_nameHuman-readable rule name
branch_nameHuman-readable branch name

​
2. Email delivery

Send formatted HTML email with embedded media. The email includes:
  • Violation alert header with rule name
  • Embedded video or image
  • Event timestamp
  • Detection thumbnail
  • Branch and brand information

​
3. Zoho Desk delivery

Create support tickets in the brand’s Zoho Desk. Tickets include:
FieldValue
SubjectRule name
DescriptionHTML-formatted violation details with image
DepartmentConfigured department ID
ContactConfigured contact ID
CategoryBrand and branch identifier

​
Configuration by brand

Each brand can configure different delivery methods in their brand settings:
IntegrationRequired configuration
Emailbusiness_action_email - recipient email address
Zohozoho.enabled, zoho.org_id, zoho.department_id, OAuth credentials
Webhookwebhook_url, optionally webhook_secret

​
Violation retrieval flow

For brands with Zoho integration, violations go through a central RIME account:
1

Violation created

Detection triggers create_violation which stores the violation in the database.
2

Ticket created in RIME Zoho

A ticket is created in RIME’s central Zoho account with status “Escalated”.
3

Retrieve and forward

The retrieve_rmts_data action fetches escalated tickets, filters by branch, and creates tickets in the brand’s Zoho account.
4

Mark as delivered

The original RIME ticket is updated to “Uploaded” status.

​
Best practices

Always include attachments

Violations without visual evidence are difficult to verify. Ensure detection actions produce both main and sub attachments.

Use descriptive notes

Include context in the violation note: zone name, detection type, confidence score.

Configure multiple channels

Set up both email and ticketing to ensure violations aren’t missed.

Monitor delivery failures

Track email bounces and Zoho API errors to catch delivery issues early.

​
Troubleshooting

Check:
  • Did detection action return is_success=true?
  • Did consolidation logic evaluate to true?
  • Did attachment upload succeed?
Look for: insert-violation calls in the logs and “Successfully created X violation(s)” messages.
Check:
  • Did detection action save files to disk?
  • Is Supabase storage accessible?
  • Are file paths in results valid?
Resolution:
  • Verify detection action is saving images
  • Check Supabase bucket permissions
  • Check network connectivity
Check:
  • Is business_action_email configured on brand?
  • Did SMTP connection succeed?
  • Is email in spam folder?
Look for: “Email sent successfully” or “Failed to send email” in logs.
Check:
  • Is zoho.enabled set to true?
  • Are OAuth credentials valid?
  • Does department/contact exist?
Look for: “Zoho ticket created with ID” or error messages with status codes in logs.

Create violation action

Detailed documentation on the create_violation business action.

Violation lifecycle

Full flow from detection to brand delivery.