Pylon

Tools 67

• Build Filter

  Build a validated filter for any object type. Returns a serialized filter_json string to pass into create_view, edit_view, create_chart, or any other tool that accepts filter_json. Workflow: 1. Discover valid fields: call get_filter_attributes for the directory, then the per-object tool it points to for your object_type (e.g. get_issue_filter_attributes). The per-object tool returns fields, operators, and reference_type annotations. If you need values for a dynamic status property, also call the matching status tool (e.g. get_issue_statuses, get_task_statuses). Status filters accept the label or slug value returned by those tools (e.g. "new" is the default New status). To match active/non-closed items, use operator not_any_of with the closed/completed status value (e.g. not_any_of ["closed"]). 2. When a property's reference_type is set ("team", "user", "account"), resolve names to UUIDs via search_teams / search_users / search_accounts before using them as values. 3. Call build_filter with the conditions. It validates fields, operators, references, and known status values. The returned filter_json has already been validated — pass it through unchanged to downstream tools. Each condition has a field (built-in property name or custom field slug), operator, and value/values. Text, Number, and URL fields (e.g. from_email, issue_title) accept a single value per condition — the filter editor renders them as one input and cannot show more. To exclude several values from one of those fields, pass one single-value not_any_of condition per value; conditions are ANDed, which is what exclusion needs. Matching any of several values is the opposite: build_filter cannot express it, because everything it returns is ANDed — ask for a separate trigger branch per value instead (see build_trigger). Most conditions filter the object's own fields (e.g. an issue's from_email or source) — leave related_object_type unset for those. Only set related_object_type to hop to a DIFFERENT related object (e.g. an issue's account); never set it equal to object_type. AI conditions: for a natural-language condition the AI evaluates per issue (e.g. "the email is a spam sales solicitation"), set type="ai" and prompt=<the condition in plain language>, and omit field/operator/value. AI conditions are only supported for object_type "issue" and are intended for trigger branch conditions (build_trigger) — do not use them in views, charts, or other filter consumers. Returns a validated serialized filter object suitable for trigger conditions and other filter-aware APIs. Issue state values use the public slugs returned by get_issue_statuses.

• Create Account

  Create a new account in the authenticated Pylon organization. Requires a name. Optionally specify an owner, domains, tags, custom fields, external IDs, and account type. Use get_custom_fields with object_type 'account' to discover available custom field slugs.

• Create Attachment

  Upload a base64-encoded file to Pylon and return its attachment ID and URL. The upload is not attached to an issue or message. Files are limited to 5 MB decoded.

• Create Issue

  Create a new issue/ticket in the authenticated Pylon organization. Requires an account ID, title, and body HTML. Optionally specify requester, priority, assignee, team, and tags.

• Create Milestone

  Create a milestone within a project.

• Create Project

  Create a project for an account. Set project_template_id to scaffold milestones, tasks, and subtasks from a project template; otherwise name is required.

• Create Project From Template

  Create a project from a project template for an account. The template's milestones, tasks, and subtasks are copied into the new project, with optional top-level overrides.

• Create Task

  Create a new task. Requires a title. Optionally specify account, project, milestone, assignee, due date, status, and visibility settings. Tasks can be associated with accounts and projects.

• Create Trigger

  Create a disabled trigger in a custom trigger group with one or more non-recurring, non-phone kickoffs and flat action/time-delay/condition steps. The trigger is always disabled so a teammate can review and enable it in Pylon. Call get_trigger_examples for canonical patterns, then use list_trigger_groups, kickoff/action discovery, and build_filter to resolve the live values. Issue state values in filters and set_issue_state actions use the public slugs returned by get_issue_statuses. Call validate_trigger with the completed payload before creating it. Actions must be compatible with every kickoff. Use a standalone conditions step as a checkpoint that stops the rest of its branch when the filter no longer matches. When describe_trigger_kickoff reports supports_front_delay, set its returned front_delay_condition.condition_key inside that kickoff's condition using the matching condition_schema. Default/special groups, recurring schedules, phone/IVR triggers, nested branches, and background-agent investigation actions are intentionally unsupported.

• Delete Task

  Delete a task by ID. This will also delete all subtasks of the task. This action cannot be undone.

• Describe Trigger Action

  Get one trigger action's canonical variables_key, exact variables schema, and compatible kickoff types. Call this before adding the action to create_trigger or update_trigger.

• Describe Trigger Kickoff

  Get one kickoff's supported condition variants and action types. For recurring_schedule, pass object_type to discover actions for that scheduled object.