Tallyfy Workflow Automation

Run your operations from your AI assistant.

Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeCan modify data

What it can do

  • Get Me: Get the currently authenticated user's profile data. No parameters required. USE THIS TOOL when user asks: - "Who am I?" - "What's my name?" - "Show my profile" - "What's my user ID?" - "What
  • Get Organization Users: Get organization members with full profile data. No required parameters. USE THIS TOOL when user asks: - "Who are the team members?" - "List all users" - "Show me organization
  • Get Organization Users List: Get all organization members with minimal profile data for listing. Returns data with pagination metadata.

What data it sees

Do you need an account

No: the server works without sign-in

Run your operations from your AI assistant. Launch workflows, complete tasks, manage approvals, and update templates in Tallyfy — all from natural conversation. Automate tasks, processes, and approvals with AI.

Server tool list (60)

Raw names from tools/list. Only developers need these.

get_meGet the currently authenticated user's profile data. No parameters required. USE THIS TOOL when user asks: - "Who am I?" - "What's my name?" - "Show my profile" - "What's my user ID?" - "What organization am I in?" Returns the authenticated user's full profile including numeric 'id', 'email', 'first_name', 'last_name', and organization details.
get_organization_usersGet organization members with full profile data. No required parameters. USE THIS TOOL when user asks: - "Who are the team members?" - "List all users" - "Show me organization members" - "Find user by name/email" (then search results for the user) Returns user data including numeric 'id', 'email', 'first_name', 'last_name'. Use the returned 'id' field when you need to call get_user_tasks(user_id=...). Optional: Set with_groups=true to include group membership information. PAGINATION: Returns 20 results per page. Use page=2, page=3, etc. for subsequent pages. meta.total_pages shows how many pages exist.
get_organization_users_listGet all organization members with minimal profile data for listing. Returns data with pagination metadata.
invite_user_to_organizationInvite a new member to the organization. MANDATORY - ALL THREE required: 1. 'email' - Valid email address 2. 'first_name' - User's first name 3. 'last_name' - User's last name CORRECT usage: - invite_user_to_organization(email="john@example.com", first_name="John", last_name="Doe") - invite_user_to_organization(email="jane@example.com", first_name="Jane", last_name="Smith", role="standard") WRONG usage (will fail): - invite_user_to_organization(email="john@example.com") - NO! Missing first_name and last_name - invite_user_to_organization(first_name="John", last_name="Doe") - NO! Missing email Optional: 'role' (light/standard/admin, defaults to 'light'), 'message' (custom invitation text). If user doesn't provide all required info, ASK them before calling this tool.
get_userGet a single user by their numeric ID. REQUIRED: 'user_id' (positive integer). Never call this without user_id.
create_guestCreate a new guest in the organization. REQUIRED: 'email' (valid email), 'first_name', 'last_name'. Optional: 'phone', 'company_name'. Never call this without the three required parameters.
update_guestUpdate guest details. REQUIRED: 'email' (valid email). Plus at least one optional field to update: 'first_name', 'last_name', 'phone', 'company_name'. Never call this without email.
disable_guestDisable a guest account. REQUIRED: 'email' (valid email). This prevents the guest from accessing the organization. Never call this without email.
enable_guestRe-enable a disabled guest account. REQUIRED: 'email' (valid email). Never call this without email.
get_guestGet a single guest's profile by email address. Returns guest profile data including name, contact info, last accessed time, and status. NOTE: This returns the guest's profile only, not their tasks. To get tasks assigned to a guest, use get_guest_tasks(guest_email="...") or get_guest_tasks(guest_id="...") with the guest_id from this response. CORRECT usage: - get_guest(email="guest@example.com")
change_user_roleChange a user's role in the organization. REQUIRED: 'user_id' (positive integer) and 'role' ('light', 'standard', or 'admin'). Never call this without both parameters.
disable_userDisable a user account. REQUIRED: 'user_id' (positive integer). This prevents the user from accessing the organization. Never call this without user_id.
enable_userRe-enable a disabled user account. REQUIRED: 'user_id' (positive integer). Never call this without user_id.
get_organizationGet organization details. No parameters required — organization is determined from authentication context.
get_my_tasksGet tasks assigned to the current user. No parameters required. USE THIS TOOL when user asks: - "What are my tasks?" - "Show me my tasks" - "What do I need to do?" - "What's assigned to me?" This tool returns task data including task IDs, run_ids (process IDs), titles, deadlines, and status. Use the returned data to answer follow-up questions about "those tasks" without making additional tool calls. IMPORTANT: Tallyfy has no urgency or priority field. For "urgent" tasks, look for status="overdue" or status="hasproblem" in the returned results. NOTE: This tool does NOT support status filtering. It returns all tasks for the current user. To filter by status, retrieve all tasks and filter the results client-side. PAGINATION: Returns 20 tasks per page. Use page=2, page=3, etc. to retrieve subsequent pages. meta.total_pages shows how many pages exist. meta.total shows the real count.
get_user_tasksGet all tasks assigned to a specific organization member (not the current user). IDENTIFICATION: Provide one of user_id, user_name, or user_email. CORRECT usage: - get_user_tasks(user_id=12345) — fastest, no lookup needed - get_user_tasks(user_name="Zurly Venom") — resolves name to ID automatically - get_user_tasks(user_email="zurly@example.com") — resolves email to ID automatically WRONG usage (will fail): - get_user_tasks() — NO! Must provide at least one identifier GUEST USERS: This tool is for org members only. For guest tasks, use get_guest_tasks(guest_email="...") or get_guest_tasks(guest_id="...") instead. For current user's tasks, use get_my_tasks() instead (no user_id needed). IMPORTANT: Tallyfy has no "urgent" or "priority" field. For urgent tasks, call with no status filter and look for status="overdue" or status="hasproblem" in results. PAGINATION: Returns 20 tasks per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count.
get_tasks_for_processGet tasks for a specific process (workflow run). MANDATORY: You MUST provide either 'process_id', 'run_id', OR 'process_name'. Calling with empty parameters WILL FAIL. CORRECT usage examples: - get_tasks_for_process(process_id="abc123") - when you have the process/run ID - get_tasks_for_process(run_id="abc123") - alias for process_id (consistent with other task tools) - get_tasks_for_process(process_name="Hiring John Doe") - when you have the process name WRONG usage (will fail): - get_tasks_for_process() - NO! Missing required parameter - get_tasks_for_process(process_id=None) - NO! Must provide a value If you don't have a process_id/run_id or process_name, use search_for_processes first or extract run_id values from previous get_my_tasks results. PAGINATION: Returns 20 tasks per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count.
create_standalone_taskCreate a standalone (one-off) task with explicit structured fields. NOTE: Tallyfy internally creates a lightweight process container for every standalone task — this is expected platform behaviour and the task will still appear as a one-off task (is_oneoff_task: true). REQUIRED FIELDS: title, deadline, and at least one assignee. DEADLINE: Accepts natural language — e.g. "April 12 2026 at 3pm", "next Monday at noon", "tomorrow at 5pm". Resolved to UTC using the org timezone automatically. TASK TYPE: Accepted values: - "task" (default) — standard task - "approval" — approval/reject task - "expiring" — expiring task - "email" — email draft task - "expiring_email" — auto-send email task ASSIGNEES: Provide one or more of: - user_names: member full names (e.g. ["John Doe"]) - user_emails: member email addresses - guest_emails: guest email addresses - group_names: group names CORRECT usage: - create_standalone_task(title="Review budget", deadline="tomorrow at 3pm", user_emails=["john@example.com"]) - create_standalone_task(title="QA test", task_type="approval", deadline="April 12 2026", user_names=["Jane Smith"], description="Routine QA validation") If the user doesn't specify a deadline or assignee, ASK them before calling the tool.
create_task_from_textCreate a one-off task from a single natural-language sentence. This tool extracts structured fields (title, task_type, assignees, deadline, description) from `user_input` using a server-side `claude -p` extraction step, then creates the task via the same SDK path as `create_standalone_task`. PREFER `create_standalone_task` whenever your client (Claude, etc.) can already extract the structured fields itself — it skips the extra LLM hop and is more deterministic. Use this tool when the caller cannot pre-extract fields. CORRECT usage: - create_task_from_text(user_input="April 11 - QA MCP test, approval type, assign to zurly@nike.com and zurlyqa+guest@gmail.com, deadline April 12 2026, description: Routine MCP QA validation") What is extracted: - title (the concise name, NOT the whole input) - task_type — one of: task | approval | expiring | email | expiring_email (or null) - assignee_emails / assignee_names — org members (resolved via existing user lookup) - guest_emails — external guests (passed directly into the task owners) - description — task summary - deadline — natural-language phrase, parsed via the same date extractor as create_standalone_task REQUIREMENTS: at least one assignee must be extractable; deadline must be parseable. TIMEZONE FALLBACK: If the user has no timezone configured on their Tallyfy profile, the deadline defaults to UTC and the response includes a `deadline_local` field annotated `(UTC — no org/user timezone configured; update Tallyfy profile settings)` so the caller can prompt the user to set their timezone.
complete_taskMark a task as complete. REQUIRED: 'run_id' (32-char hex process ID) and 'task_id' (32-char hex). ⚠️ APPROVAL TASKS — MANDATORY is_approved PARAMETER ⚠️ If the task is an approval-type step (`step_type` = "approval"), you MUST provide EITHER `is_approved=True` (approve) OR `is_approved=False` (reject). The API rejects the request with HTTP 422 "The is approved field is required" if you omit `is_approved` on approval tasks. Before calling, check `step_type` on the task (via get_task or get_tasks_for_process): - step_type="task" → DO NOT pass is_approved (regular completion) - step_type="approval" → MUST pass is_approved=True or is_approved=False - step_type="expiring" → DO NOT pass is_approved (regular completion) - step_type="email" → DO NOT pass is_approved (regular completion) When calling on a regular (non-approval) task with `is_approved`, the parameter is ignored (no error). When calling on an approval task WITHOUT `is_approved`, the API returns 422. CORRECT usage: complete_task(run_id="abc123...", task_id="def456...") # regular task complete_task(run_id="abc123...", task_id="def456...", is_approved=True) # approve an approval task complete_task(run_id="abc123...", task_id="def456...", is_approved=False) # reject an approval task HOW TO GET run_id, task_id, and step_type: - Use get_tasks_for_process() or get_my_tasks() to find tasks with their run_ids, IDs, and step_type. Never call this without both required parameters.
reopen_taskReopen a previously completed task. REQUIRED: 'run_id' (32-char hex process ID), 'task_id' (32-char hex), and 'reason' (string explanation for reopening). ⚠️ MANDATORY `reason` PARAMETER: - The `reason` parameter is REQUIRED (not optional) — empty/whitespace-only strings raise ToolError. - It mirrors the native Tallyfy UI, which requires a reason before reopening. - The reason is automatically posted as a comment on the task for audit trail purposes — visible to all task participants and persisted permanently in the run history. - Length: keep it concise (1-2 sentences, ideally under 500 characters). Very long reasons are accepted by the API but may be truncated in some UI views. - YOU MUST ASK THE USER for the reason before calling this tool. Do NOT invent, assume, or fabricate a reason — that would create a misleading audit trail. WHY: Reopening a task is a corrective action that affects workflow integrity. The audit comment ensures team members (assignees, owners, observers) understand WHY the task was reopened — preventing confusion ("Was the previous completion wrong? Did requirements change?"). CORRECT usage: reopen_task(run_id="abc...", task_id="def...", reason="Incorrect completion, needs review") reopen_task(run_id="abc...", task_id="def...", reason="Customer reported issue not addressed; reopening for follow-up.") WRONG usage (will fail or create a misleading audit): reopen_task(run_id="abc...", task_id="def...") # MISSING reason → ToolError reopen_task(run_id="abc...", task_id="def...", reason="") # EMPTY reason → ToolError reopen_task(run_id="abc...", task_id="def...", reason="reopening") # AI-fabricated → misleading audit Never call this without all three required parameters. Always ask the user to provide the reason.
update_taskUpdate task properties including deadline, assignees, title, or form field values. REQUIRED: 'run_id' (32-char hex process ID) and 'task_id' (32-char hex). Plus at least ONE optional field to update. CORRECT usage: update_task(run_id="abc...", task_id="def...", deadline="2026-03-01 17:00:00") update_task(run_id="abc...", task_id="def...", title="New title", summary="Updated description") update_task(run_id="abc...", task_id="def...", owners={"users": [123], "guests": []}) Never call this without run_id and task_id.
get_taskGet a single task from a process by ID. REQUIRED: 'run_id' (32-char hex process ID) and 'task_id' (32-char hex). Never call this without both parameters.
get_standalone_taskGet a standalone (one-off) task by ID. REQUIRED: 'task_id' (32-char hex). Never call this without task_id.
update_standalone_taskUpdate a standalone (one-off) task that was created via create_standalone_task. Use THIS tool (not update_task) when the task has no run_id or was created as a one-off task. Use update_task instead when the task belongs to a workflow process run. REQUIRED: 'task_id' (32-char hex) plus at least ONE field to update. CORRECT usage: update_standalone_task(task_id="abc...", deadline="2026-06-01 17:00:00") update_standalone_task(task_id="abc...", title="New title", summary="Updated description") update_standalone_task(task_id="abc...", owners={"users": [123], "guests": [], "groups": []}) update_standalone_task(task_id="abc...", taskdata={"field_timeline_id": {"value": "new value"}}) Never call this without task_id. Do NOT pass a run_id — standalone tasks don't use one.
complete_kickoff_formComplete a process kickoff form to mark it as submitted. REQUIRED: 'run_id' (32-char hex process ID). Never call this without run_id.
get_guest_tasksGet all tasks assigned to a specific guest (external user). IDENTIFICATION: Provide guest_id or guest_email. CORRECT usage: - get_guest_tasks(guest_id="MITxZa1z2f5d81bb53f1da7c7fa95a2cfec5cbc2") — fastest, no lookup needed - get_guest_tasks(guest_email="guest@example.com") — resolves email to guest_id automatically WRONG usage (will fail): - get_guest_tasks() — NO! Must provide at least one identifier For org member tasks, use get_user_tasks() instead. For the current user's tasks, use get_my_tasks() (no identifier needed). IMPORTANT: Tallyfy has no "urgent" or "priority" field. For urgent tasks, call with no status filter and look for status="overdue" or status="hasproblem" in results. PAGINATION: Returns 20 tasks per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count.
get_organization_runsGet workflow processes (runs) in the organization. All parameters are optional — call with no parameters to get all runs, or use filters to narrow results. FILTERS: status, archived, starred, checklist_id (template_id), tag, folder, groups, owners, run_type, me (bool) RUN STATUS VALUES: "active", "problem", "delayed", "complete" ARCHIVED: Use archived="only" to get archived processes (NOT status="archived"). RUN TYPE VALUES: "procedure", "form", "document" FOLDER: Pass folder ID or folder name (name is auto-resolved to ID). OWNERS: Pass numeric user IDs. Filters by collaborator presence (run owner OR task assignee) — NOT by strict process creator/started_by. Use owners= to find runs the user is involved in, not runs they personally launched. PAGINATION: Returns 20 results per page. Use page=2, page=3, etc. to retrieve subsequent pages. meta.total_pages shows how many pages exist. meta.total shows the real count.
launch_processLaunch a new workflow process (run) from a template. REQUIRED: 'template_id' (32-char hex) and 'name' (process name string). For the name, generate a short descriptive instance name based on the template name and context (e.g. "Onboarding - Jane Doe", "Q1 Budget Review - Marketing"). Do not ask the user for a name unless they want to specify one. PRERUN vs STEP-FORM-FIELDS — TWO DIFFERENT FORM SURFACES: - `prerun` (optional list): KICKOFF FORM fields — initialization data collected BEFORE the workflow starts. These are the form fields the user fills in on the launch screen (e.g. "Customer name", "Project ID", "Department"). Defined at the TEMPLATE level (not on a specific step). Use `get_kickoff_fields(template_id)` to discover available kickoff field IDs. Format: list of {"<kickoff_field_id>": "<value>"} entries. Example: prerun=[{"abc123def456...": "Acme Corp"}, {"xyz789abc...": "2026-01-15"}] - Step-level form fields (NOT set here — set later via `update_task`): Filled in DURING workflow execution as steps run. To set a step's form-field values, complete or update the relevant task with `update_task` and pass `taskdata={field_id: value, ...}`. These are NOT prerun fields. Rule of thumb: If the user provides data BEFORE launching the workflow, it goes in `prerun`. If they provide data WHILE doing tasks, it goes in `update_task.taskdata`. CORRECT usage: launch_process(template_id="abc123...", name="Onboarding - Jane Doe") launch_process(template_id="abc123...", name="Q1 Review", tags=["tag_id"], folders=["folder_id"]) launch_process( template_id="abc123...", name="Onboarding - Acme", prerun=[{"<customer_name_field_id>": "Acme Corp"}, {"<start_date_field_id>": "2026-01-15"}], owner_id=12345, folders=["<folder_id>"] ) WRONG usage (will fail): launch_process(template_id="abc123...") ← MISSING name launch_process(name="Review") ← MISSING template_id
get_processGet full details for a single process (run) by ID. REQUIRED: 'run_id' (32-char hex). Never call this without run_id.
update_processUpdate a process name, summary, or starred status. REQUIRED: 'run_id' (32-char hex) plus at least one of: 'name', 'summary', or 'starred'. Never call this without run_id.
archive_processArchive a completed process (run). REQUIRED: 'run_id' (32-char hex). CAUTION: Archived processes are HIDDEN from default views but NOT deleted — all data, tasks, comments, and form-field captures are preserved. Use reactivate_process(run_id) to restore an archived process to active status. To permanently delete a process you must use the universal API fallback (tallyfy_api_call) since no first-class delete tool is exposed. Archived processes can be retrieved via get_organization_runs(archived='only'). Never call this without run_id.
reactivate_processReactivate an archived process (run) to make it active again. REQUIRED: 'run_id' (32-char hex). Never call this without run_id.
reopen_kickoff_formReopen a completed kickoff form to allow edits. REQUIRED: 'run_id' (32-char hex process ID). Never call this without run_id.
search_for_tasksSearch for tasks in the organization by keyword. MANDATORY: You MUST provide a 'query' parameter. Calling with empty/missing query WILL FAIL. CORRECT usage examples: - search_for_tasks(query="urgent") - search for urgent tasks - search_for_tasks(query="review document") - search for document review tasks - search_for_tasks(query="approval") - search for approval-related tasks WRONG usage (will fail): - search_for_tasks() - NO! Missing required query parameter - search_for_tasks(query="") - NO! Empty query not allowed Extract search terms from user's request. If user says "find my tasks about reports", use query="reports". PAGINATION: Returns 20 results per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count.
search_for_processesSearch for workflow processes (runs) in the organization by keyword. MANDATORY: You MUST provide a 'query' parameter. Calling with empty/missing query WILL FAIL. CORRECT usage examples: - search_for_processes(query="onboarding") - search for onboarding processes - search_for_processes(query="John Doe") - search for processes related to John Doe - search_for_processes(query="Q4 report") - search for Q4 report processes WRONG usage (will fail): - search_for_processes() - NO! Missing required query parameter - search_for_processes(query="") - NO! Empty query not allowed Extract search terms from user's request. If user says "find the hiring process for Sarah", use query="hiring Sarah". PAGINATION: Returns 20 results per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count.
search_for_templatesSearch for workflow templates (blueprints) in the organization by keyword. MANDATORY: You MUST provide a 'query' parameter. Calling with empty/missing query WILL FAIL. CORRECT usage examples: - search_for_templates(query="onboarding") - search for onboarding templates - search_for_templates(query="HR") - search for HR-related templates - search_for_templates(query="approval workflow") - search for approval templates WRONG usage (will fail): - search_for_templates() - NO! Missing required query parameter - search_for_templates(query="") - NO! Empty query not allowed Extract search terms from user's request. If user says "show me HR templates", use query="HR". If user wants ALL templates without filtering, use get_all_templates() instead. PAGINATION: Returns 20 results per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count.
search_for_snippetsSearch for text snippets (stored text templates) in the organization by keyword. MANDATORY: You MUST provide a 'query' parameter. Calling with empty/missing query WILL FAIL. CORRECT usage examples: - search_for_snippets(query="welcome email") - search for welcome email snippets - search_for_snippets(query="disclaimer") - search for disclaimer snippets WRONG usage (will fail): - search_for_snippets() - NO! Missing required query parameter - search_for_snippets(query="") - NO! Empty query not allowed Extract search terms from user's request. If user says "find the thank you snippet", use query="thank you". PAGINATION: Returns 20 results per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count.
search_allSearch across multiple entity types in one request. Returns results grouped by type. MANDATORY: You MUST provide a 'query' parameter. Calling with empty/missing query WILL FAIL. Searches blueprints, processes, tasks, and snippets by default. Use the 'types' parameter to narrow down. Valid types: blueprint, process, task, snippet, capture, step. PAGINATION: Returns 20 items per page per entity type by default. Use page=2, page=3 for more results, or per_page to change page size (max 100). CORRECT usage examples: - search_all(query="onboarding") - search everything for "onboarding" - search_all(query="Q4", types=["process", "task"]) - search only processes and tasks - search_all(query="report", per_page=10) - search with fewer results per type - search_all(query="onboarding", page=2) - second page of results WRONG usage (will fail): - search_all() - NO! Missing required query parameter - search_all(query="") - NO! Empty query not allowed
get_templateGet a template (checklist) by its ID or name with full details. MANDATORY: You MUST provide either 'template_id' OR 'template_name'. Calling with empty parameters WILL FAIL. CORRECT usage examples: - get_template(template_id="abc123def456") - when you have the template ID from a previous result - get_template(template_name="Employee Onboarding") - when you know the template name WRONG usage (will fail): - get_template() - NO! Missing required parameter - get_template(template_id="", template_name="") - NO! Must provide a value for one If you don't have a template_id or name, use search_for_templates(query="...") first to find templates, or use get_all_templates() to list all templates. DO NOT use this tool just to list steps — use get_template_steps instead.
get_all_templatesGet templates (checklists) with full details including prerun fields, automated actions, linked tasks, and metadata. Returns 20 per page. Use page=2, page=3, etc. for more. meta.total_pages shows total page count. Optional: filter by folder name or folder ID.
get_step_dependenciesRead-only: analyze which automations affect when this step appears in the workflow. Inspects all template rules referencing the step as condition trigger OR action target. RETURN: {step_info: {id,title,position,summary}, dependencies: {incoming: [{step_id,step_title,condition_type,automation_id,description}], outgoing: [{step_id,step_title,action_type,automation_id,description}], field_dependencies: [{field_label,expected_value,condition_type,automation_id,description}], conditional_visibility: [{action_type:"show_step"|"hide_step",automation_id,description}]}, complexity_analysis: {score:0-100, level:"Low"|"Medium"|"High", total_dependencies, incoming_count, outgoing_count, field_dependencies_count, visibility_conditions_count}, recommendations: [advisory strings], template_id} KEY: `conditional_visibility` lists automation_ids of show/hide rules for this step. Look them up via `analyze_template_automations` or `get_step_visibility_conditions` for full conditions. USE CASES: "What does this step depend on?"→incoming · "What does this step trigger?"→outgoing · "Which fields gate it?"→field_dependencies · "Is visibility conditional?"→conditional_visibility · "Should this step be split?"→complexity_analysis.level EXAMPLE: get_step_dependencies(template_id="58c03f...", step_id="9bc2...") → {step_info:{title:"Manager approval",position:4}, dependencies:{incoming:[{step_title:"Submit request",condition_type:"task_completed"}], outgoing:[{step_title:"Notify employee",action_type:"send_email"}], field_dependencies:[{field_label:"Amount",expected_value:">1000"}]}, complexity_analysis:{score:35,level:"Medium"}, recommendations:["Consider extracting the amount-gate"]} REQUIRED: 'template_id' AND 'step_id' (both 32-char hex). Never call without both.
suggest_step_deadlineRetrieve step details with template context to recommend an appropriate deadline. Returns the step's title, summary, position in the workflow, current deadline (if any), assignees, and the total number of steps in the template. Use this data to suggest a reasonable deadline by considering: - Step complexity (review/approve steps are quick; document creation takes longer) - Position in workflow (early steps may need faster turnaround) - Dependencies and assignee count - Whether the step has form fields that require data gathering Suggest deadlines using: value (number), unit ('minutes', 'hours', 'days', 'weeks'), and option ('from' = relative to process launch). REQUIRED: Both 'template_id' and 'step_id' must be provided (32-character hex strings). Never call this without both parameters.
add_assignees_to_stepAdd assignees (users or guests or both) to a specific step in a template. REQUIRED: 'template_id' (32-char hex), 'step_id' (32-char hex), and 'assignees'. 'assignees' accepts the following format: Dict with 'users' and/or 'guests' keys (to add guests by email): assignees: {"users": [10026], "guests": ["alice@example.com"]} assignees: {"guests": ["alice@example.com"]} assignees: {"users": [10026]} Never call this without all three parameters.
edit_description_on_stepEdit the description/summary of a specific step in a template. The description supports HTML — use this to add rich instructions, checklists, or converted document content to a step. When a user wants to convert a document to step instructions, read the document content yourself and write the HTML here. REQUIRED: 'template_id' (32-char hex), 'step_id' (32-char hex), and 'description' (new text, HTML allowed). Never call this without all three parameters.
add_step_to_templateAdd a new step to a template. Call this repeatedly after create_template to build out the workflow structure — one call per step, in order. When building a template from a user description or document, break the workflow into logical steps and call this for each one. REQUIRED: 'template_id' (32-char hex) and 'step_data' (dict with 'title' field — other fields optional). step_data keys: - 'title': step name (REQUIRED) - 'description': HTML instructions for the step assignee - 'position': 1-based order in the workflow - 'step_type': one of these 5 values (default 'task'): 'task' — standard task, completed by assignee 'approval' — approve/reject decision (MUST use this for any approval or review step — enables 'approved'/'rejected' automation conditions) 'expiring' — auto-completes after deadline passes 'email' — sends an email notification 'expiring_email' — sends email, auto-completes after deadline IMPORTANT: If a step involves approval, review, or sign-off, set step_type='approval'. Without this, automation rules that trigger on 'approved' or 'rejected' will not work. If a step is a notification or email alert, use 'email'. Never call this without both parameters.
suggest_kickoff_fieldsRetrieve template data with existing kickoff fields and step context to recommend new kickoff fields. Returns the template title, summary, existing prerun/kickoff fields, and step titles/summaries. Use this data to suggest kickoff fields that would help initialize the workflow by considering: - What information the steps will need (client names, project details, dates, budgets) - What existing kickoff fields already capture (avoid duplicates) - The template's domain and purpose (inferred from title, summary, and step content) - Field types: text, textarea, date, dropdown, number, file REQUIRED: 'template_id' (32-character hex string). Never call this without the template_id parameter.
get_kickoff_fieldsGet all kickoff/prerun fields for a template. REQUIRED: 'template_id' (32-character hex string). Never call this without the template_id parameter.
get_template_stepsGet all steps for a template in order. USE THIS instead of get_template when the user asks about steps. MANDATORY: 'template_id' (32-char hex string) is required. USE THIS TOOL when the user asks: - "What are the steps in [template]?" - "List the steps of [template]" - "Show me the steps for [template]" - Any question about a template's steps or structure - Finding a step's ID before editing or assigning it WORKFLOW: If you don't have the template_id yet: 1. Call search_for_templates(query="<template name>") to get the template_id 2. Then call get_template_steps(template_id="<id>") CORRECT usage: - get_template_steps(template_id="abc123...") DO NOT call get_template just to read its steps — use this tool instead.
assess_template_healthRetrieve complete template data for a comprehensive health assessment. Returns the full template including metadata, steps, automation rules, and kickoff fields. Use this data to evaluate template health across these dimensions: - Metadata quality: Does it have a clear title, summary, and guidance? - Step clarity: Do steps have descriptive titles and summaries? Are any too vague? - Form completeness: Do steps that need data collection have appropriate form fields? - Automation efficiency: Are automation rules well-structured? Any conflicts or redundancies? - Deadline configuration: Do time-sensitive steps have reasonable deadlines? - Workflow structure: Is the step count manageable? Is the flow logical? Provide an overall health rating (excellent/good/fair/poor/critical) with specific recommendations. RETURNS: full template payload — top-level keys include `id`, `title`, `summary`, `steps[]`, `automated_actions[]`, `prerun[]` (kickoff fields), and metadata. Synthesize this into a `health_rating` (one of: excellent, good, fair, poor, critical) plus a `recommendations` list (string array of specific, actionable improvements). The tool returns RAW data — the LLM is responsible for the rating + recommendations synthesis. REQUIRED: 'template_id' (32-character hex string). Never call this without the template_id parameter.
update_templateUpdate a template's metadata (title, summary, settings). REQUIRED: 'template_id' (32-char hex) plus at least one property to update. Updatable fields: title, summary, guidance, icon, alias, webhook, is_public, is_featured, auto_naming, folderize_process, allow_launcher_change_name, is_pinned, default_folder, kickoff_title, kickoff_description. CORRECT usage: update_template(template_id="abc123...", title="New Template Name") update_template(template_id="abc123...", summary="Updated description", is_public=True) Never call this without template_id.
clone_templateClone (duplicate) a template with a new name. REQUIRED: 'template_id' (32-char hex) and 'new_name' (string). CORRECT usage: clone_template(template_id="abc123...", new_name="Employee Onboarding v2") clone_template(template_id="abc123...", new_name="Copy of Template", copy_permissions=True) Never call this without both required parameters.
create_templateCreate a new template (checklist/blueprint). This is the first step when building a workflow from a user's description, uploaded document, or image — create the template shell here, then call add_step_to_template for each step, add_form_field_to_step for form fields, add_kickoff_field for pre-launch fields, and create_automation_rule for if-then logic. REQUIRED: 'title' (template name). Optional: 'type' ('procedure' for multi-step workflows, 'form' for data collection, 'document' for reference docs), 'summary', 'guidance', 'starred'. Never call this without title.
delete_templateDelete a template permanently. REQUIRED: 'template_id' (32-char hex). This action cannot be undone — all steps and automation rules will be deleted. Never call this without template_id.
delete_stepDelete a step from a template permanently. REQUIRED: 'template_id' (32-char hex) and 'step_id' (32-char hex). This action cannot be undone. Never call this without both parameters. NOTE: Deleting a step also removes any automation rules that reference it (as conditionable_id, target_step_id, or in then_actions); orphaned rules are pruned server-side. If you need to preserve those rules, update them to reference a different step BEFORE deleting.
clone_stepClone (duplicate) a step within a template. REQUIRED: 'template_id' (32-char hex) and 'step_id' (32-char hex). Creates an exact copy of the step including form fields and assignees. Never call this without both parameters.
reorder_stepMove a step to a new position in a template. REQUIRED: 'template_id' (32-char hex), 'step_id' (32-char hex), and 'position' (integer >= 0). Never call this without all three parameters.
add_form_field_to_stepAdd form fields (text, dropdown, date, etc.) to a step. REQUIRED: 'template_id' (32-char hex), 'step_id' (32-char hex), and 'field_data' (dict). SUPPORTED `field_type` ENUM (9 values — must be one of these exactly): - `text` single-line text input - `textarea` multi-line text input (free-form notes) - `date` date picker (yyyy-mm-dd) - `dropdown` single-select from a list of options - `multiselect` multi-select from a list of options (checkbox-style) - `radio` single-select radio buttons (mutually exclusive) - `file` file upload - `table` tabular data with named columns (REQUIRES `columns` list) - `assignees_form` member/assignee picker (the "person" field type) CONVENIENCE ALIASES (auto-resolved): `assignee`, `assignee_picker`, `member`, `member_picker` → `assignees_form`. CONDITIONAL REQUIRED `field_data` KEYS (per field_type): - `dropdown` / `radio` / `multiselect`: REQUIRE `options` — list of {text|label, optional id} - `table`: REQUIRES `columns` — list of {label, optional id} (id auto-assigned sequentially if omitted) ALWAYS-REQUIRED `field_data` KEYS: `field_type`, `label`, `required` (bool). Optional: `description`, `placeholder`, `validation`, `position`, `alias`. CORRECT usage: add_form_field_to_step(template_id="abc...", step_id="def...", field_data={"field_type":"dropdown","label":"Priority","required":True, "options":[{"id":1,"text":"High"},{"id":2,"text":"Medium"},{"id":3,"text":"Low"}]}) add_form_field_to_step(template_id="abc...", step_id="def...", field_data={"field_type":"text","label":"Customer Name","required":True}) Never call this without all three parameters.
update_form_fieldUpdate form field properties, validation, or options on an existing form field. REQUIRED: 'template_id' (32-char hex), 'step_id' (32-char hex), 'field_id' (32-char hex), and 'field_data' (dict). UPDATABLE vs IMMUTABLE PROPERTIES: UPDATABLE: - `label` human-readable name - `description` help/instruction text - `placeholder` placeholder shown in empty input - `required` mandatory flag (bool) - `validation` validation rules object - `position` ordering within the step - `options` (dropdown/radio/multiselect ONLY) — prefer `update_dropdown_options` for cleaner semantics - `columns` (table fields ONLY) IMMUTABLE (CANNOT be changed — would corrupt existing data): - `field_type` To change a field's type: `delete_form_field` then `add_form_field_to_step`. WARNING: Deletion drops ALL collected data for that field. - `id` Permanent. - `alias` Set on creation; changing breaks automation rules and references. AUTO-FILLED: The API requires `label`, `field_type`, `required` on every update. If you omit any, this tool fetches the current field and fills them in. To update only the `description`, pass `field_data={"description":"..."}` — the others auto-fill. field_type enum (reference — NOT updatable): text, textarea, date, dropdown, multiselect, radio, file, table, assignees_form CORRECT usage: update_form_field(template_id="abc...", step_id="def...", field_id="ghi...", field_data={"label":"Customer Name (legal)","required":True}) # partial — field_type/required auto-filled from current state: update_form_field(template_id="abc...", step_id="def...", field_id="ghi...", field_data={"description":"Use the legal entity name from the contract"}) WRONG usage: field_data={"field_type":"textarea"} # Cannot change type — delete + recreate instead Never call this without all four parameters.
move_form_fieldMove form field between steps with position control. REQUIRED: 'template_id' (32-char hex), 'from_step' (32-char hex), 'field_id' (32-char hex), and 'to_step' (32-char hex). Optional: 'position' (defaults to 1). Never call this without the four required parameters.
Tallyfy Workflow Automation: connect to Claude, ChatGPT, Cursor · Connectors.fun