This guide covers how Sparrow Intel creates tasks in external task management systems — both manually from the UI and automatically through rules. It details what data gets populated in each integration, how cleaning and maintenance issues receive special handling, and the differences between each supported platform.

Two Paths to Task Creation

1. Manual Task Creation (from the UI)

Users can manually create a task from a review or conversation by clicking "Create Task" in the review detail view. This opens a form (CreateTaskActionForm) with the following fields:

• Task Source — Which integration to create the task in (dropdown of connected integrations)

• Department — Cleaning, Maintenance, or Inspection (radio buttons)

• Title — Free-text title for the task

• Description — Free-text multi-line description

• Assignee — User from the selected integration (autocomplete, optional)

• Project — Only shown when Asana is selected (required for Asana)

• Scheduled At — Optional date/time picker

• Task Template — Only shown when the integration supports templates (e.g., Breezeway)

• Tags — Only shown when the integration supports tags (e.g., Breezeway), multi-select

The user has full control over all fields. The form dynamically shows/hides fields based on which integration is selected and what that integration supports.

2. Automatic Task Creation (via Rules)

Rules trigger task creation automatically when conditions are met (e.g., "When a review has maintenance issues AND property is in group X, create a Breezeway task"). The rule engine constructs task parameters based on the rule configuration:

• Title — Auto-generated based on the rule and its conditions

• Description — Auto-generated with a summary of all matched conditions

• Checklist — Auto-generated from detected issues (cleaning/maintenance)

• Assignee — Configured on the rule action

• Department — Auto-set based on the type of issues detected

• Template, Tags, Project — Configured on the rule action (for integrations that support them)

Cleaning & Maintenance Issues: Special Handling

This is the most important behavioral difference in Sparrow's task creation logic. When a rule includes a Maintenance Issues or Cleaning Issues condition, Sparrow creates tasks differently than it does for other condition types.

Standard Task Creation (non-issue conditions)

For rules that don't involve cleaning or maintenance issues (e.g., "When overall rating is less than 3"), Sparrow creates one task per rule trigger with:

• Title: "{Rule Title} (from Sparrow)"

• Description: A formatted summary of all conditions and their values

• Checklist: Empty (no checklist items)

• Department: Not set (null)

Issue-Based Task Creation (cleaning or maintenance conditions)

When a rule includes a cleaning or maintenance issues condition, Sparrow creates one task per individual issue. For example, if a review mentions 3 maintenance issues ("broken faucet", "cracked window", "loose door handle"), Sparrow creates 3 separate tasks.

Each per-issue task gets:

• Title:

  • Single-condition rule: "{issue} (from Sparrow)" — e.g., "Broken faucet in bathroom (from Sparrow)"

  • Multi-condition rule: "{issue} (from Sparrow: {Rule Title})" — e.g., "Broken faucet in bathroom (from Sparrow: Beachfront Maintenance)"

• Description: "{condition description}: {issue}" — e.g., "Has Maintenance Issues: Broken faucet in bathroom"

• Checklist: Contains the single issue as a checklist item

• Department: Automatically set to Maintenance for maintenance issues, Cleaning for cleaning issues

Why this matters

The per-issue enumeration ensures that:

1. Each issue becomes an actionable, trackable task in the external system rather than being buried in a single generic task

2. Assignees see specific work — "Fix broken faucet" is far more useful than "Maintenance issues detected"

3. Both issue types can fire on the same rule — If a rule has both cleaning and maintenance conditions, both sets of issues get enumerated into separate tasks with the correct departments

4. Multi-condition rules still work — A rule like "Property Group = Beachfront AND Has Maintenance Issues" will still enumerate individual issues. The title includes the rule name for context.

Integration-by-Integration Guide

Breezeway

Breezeway is the most feature-rich task integration, supporting templates, tags, departments, and scheduled dates.

What gets populated:

What is NOT populated:

• Checklist items are not sent to Breezeway (the API field is not used)

If no department is specified, defaults to Inspection.

Task templates: Breezeway supports task templates which pre-fill certain fields. When creating a rule with Breezeway as the target, users can select a template. Templates are fetched from Breezeway and filtered by department.

Tags: Breezeway supports task tags for categorization. Users can select multiple tags when creating a rule or manual task.

Guesty

Guesty supports the core task fields plus native checklists and scheduling.

What gets populated:

What is NOT populated:

• Priority is hardcoded to "medium"

Department mapping:

Checklist behavior: Guesty natively supports checklists on tasks. When Sparrow creates a task with checklist items (e.g., from detected issues), each item appears as a checkable item in Guesty's task view.

Hostaway

Hostaway supports checklists and scheduling but does not natively support departments on task creation.

What gets populated:

What is NOT populated:

• Department — not sent in the create task API call. While Hostaway uses a categoriesMap internally (1=cleaning, 2=maintenance, 3=check-in, 4=check-out, 5=back office, 6=other), this is not set when creating tasks via API

Department mapping (for task retrieval only, not creation):

Track

Track routes to completely different API endpoints based on the department. There is no single "create task" endpoint — the department determines which Track subsystem receives the task.

Department-based routing:

Cleaning Department → Housekeeping Work Order

Additional: Track creates/fetches a "SPARROW" clean type (cleanTypeId) for these work orders.

Maintenance Department → Maintenance Work Order

Additional: dateReceived is hardcoded to today, estimatedTime to 60 minutes, estimatedCost to 0.

Inspection or Default → CRM Task

Additional: priority is hardcoded to 3.

What is NOT populated (all Track types):

• Checklists (not supported by any Track endpoint)

Key takeaway for Track: The department field is critical for Track because it determines not just a label but which entirely different system (housekeeping vs. maintenance vs. CRM) receives the task. This is why the special handling for cleaning/maintenance issues matters — it ensures the correct department is set and the task lands in the right Track subsystem.

Asana

Asana requires a project for every task and puts most detail into a single notes field since Asana's task model is simpler.

What gets populated:

How the notes field is constructed:

Asana doesn't have separate fields for description, department, and checklist like some other integrations. Instead, Sparrow concatenates all information into the notes field in this order:

1. Description text

2. Reservation ID (if available)

3. Department label

4. Checklist items (as a bulleted list)

Project requirement: Unlike other integrations, Asana requires a project to be specified. When creating a rule with Asana as the target, users must select which Asana project tasks should be created in. This project selector appears as the secondary input on the rule action and as a required field on the manual task creation form.

Webhook

The webhook integration sends a JSON payload to a user-specified URL. It does not create tasks in any specific system — instead, it provides all the data needed for the receiving system to create tasks however it sees fit.

Payload structure:

{ "event": "rule.triggered", "ruleId": "guid", "ruleTitle": "Rule name", "propertyManagerId": "guid", "companyName": "Company name", "targetType": "Review | ReviewPrediction | VoiceConversation | ConversationPost", "targetId": "guid", "task": { "title": "Task title", "description": "Task description", "checklist": ["item1", "item2"], "department": "Cleaning | Maintenance | Inspection" }, "review": { ... }, "reviewPrediction": { ... }, "voiceConversation": { ... }, "conversationPost": { ... } } 

Only the relevant target field is populated (e.g., if the trigger was a review, only review contains data).

What gets populated in task:

Key differences from other integrations:

• Sends the full context of the triggering entity (entire review, voice conversation, etc.)

• No assignee field — the receiving system handles assignment

• No scheduling

• The URL is specified per-rule as the action data

• Multiple tasks (e.g., from enumerated cleaning issues) result in multiple webhook calls