Using the Autotask PSA extension

The Autotask PSA extension lets a CloudRadial AutomationAI workflow or agent read and write your Autotask data — tickets, companies, contacts, configuration items, tasks, and projects — from one set of API credentials. This article covers what the extension can do, the lookup tools that resolve the ids Autotask requires, and how to work with companies and configuration items. It is for workspace users who build automations (Admin or Owner Role).

As of version 2.5.7, creating a company requires an account owner (ownerResourceID). A workflow, script step, or Extension tool node that calls at_create_company without an owner now fails validation before anything is sent to Autotask. If you have existing workflows that create companies, add an owner to those calls. See Working With Companies.

• Installing the Extension
• What the Extension Covers
• Resolving Required Ids
• Working With Companies
• Working With Configuration Items
• Approval and Preview

Installing the Extension

Open Extensions (/extensions), find Autotask PSA in the catalog, and install it. You supply the API user credentials Autotask issues for integrations; AutomationAI stores them for your workspace and the runner reads them at run time. The extension needs four secrets:

• Autotask-ApiUrl: your zone host only, for example https://webservices2.autotask.net, with no path. The extension adds /atservicesrest/v1.0 to every call itself, so a full REST URL makes every request fail. To find your zone, call https://webservices.autotask.net/atservicesrest/v1.0/zoneInformation?user=YOUR_API_USER and use the host from its url. Use the webservicesN.autotask.net host, not the wwN.autotask.net address you see in your browser; that one is the Autotask web interface, not the API.
• Autotask-ApiIntegrationCode: the API tracking identifier from your Autotask integration.
• Autotask-Username: the API user's username.
• Autotask-Secret: the API user's secret.

If every call fails with HTTP 403 "Access Denied," the request never reached the Autotask API. That is a setup problem, not missing data: check that Autotask-ApiUrl is a webservicesN host and that the API user and integration code are valid. The agent reports the failure and stops rather than retrying.

See Browsing and installing extensions for the general install flow, and Managing companies and per-company credentials if you run a separate Autotask instance per client.

What the Extension Covers

Version 2.5.7 of the extension has 33 tools and 6 skills. Of the tools, 22 only read data and run without approval; the other 11 create or change records and always ask for approval first. The tools cover the areas an automation usually needs:

• Tickets — query, create, update, and add notes
• Companies — query, create, and update
• Contacts — query and create
• Configuration items — query, create, and update
• Tasks and projects — query and create
• Time entries — query and create
• Lookups — resolve the ids the write tools require

Resolving Required Ids

Several Autotask fields are mandatory on create and take an id rather than a name — a role, a billing code, a note type, a task or project status. An agent has no way to invent those ids correctly, so the extension ships lookup tools that fetch them from your own Autotask instance:

• A general field-values lookup that returns the allowed values for a field on a given entity, covering company type, note type, publish, and task and project status
• A roles lookup, for the role and assigned-resource-role fields
• A billing codes lookup, for the billing code field

Roles and billing codes are not simple picklists in Autotask — they are records in their own right — which is why they have their own lookups rather than appearing in the field-values list. When you build a workflow that creates Autotask records, put the matching lookup ahead of the create step so the id is resolved from live data rather than hard-coded.

Agents ask rather than guess. When a required value is missing, the agent asks you for it, in one question covering everything it still needs, instead of sending a placeholder such as 000-000-0000 for a phone number.

Working With Companies

Creating a company (at_create_company) requires a company name, a company type, and an account owner (ownerResourceID). The owner must be an active, licensed Autotask resource whose security level has access to the CRM module; Autotask rejects an API-only user. An agent picks the owner this way:

• The resource you named, if you named one
• Otherwise, the one active resource whose email matches the person who asked
• Otherwise, it asks you. It never picks an owner on its own.

If you call the tool from a workflow or an Extension tool node, pass the owner explicitly. A call without it fails validation before any request is sent to Autotask.

To build a parent/child structure, create or find the parent company first, then create each child with the parent's id in the optional parentCompanyID field. The parent must be a top-level company: Autotask allows one level of children, so a company that already has a parent can't be a parent itself. Before each create, the agent checks for a company with the exact same name so it doesn't make a duplicate.

To change an existing company, use the update tool (at_update_company). It requires approval, like every write, and can:

• Move a company under a top-level parent (parentCompanyID)
• Rename it (companyName)
• Change the account owner (ownerResourceID) or main phone number (phone)
• Deactivate or reactivate it (isActive, true or false)

The Autotask API can't delete a company. To retire one, deactivate it by setting isActive to false.

Working With Configuration Items

Autotask keeps two distinct fields on a configuration item, and it is easy to confuse them:

• Type is required on create. Autotask retains it for older integrations
• Category is optional, and is how assets are organized in current Autotask

Both have their own lookup tool. Set the category explicitly when you create or update an asset; leave it out and the asset lands in your Autotask instance’s default category, which is rarely what you want when you are filing assets for a specific client.

Set the active flag explicitly when you create a configuration item, too. The create tool accepts an optional isActive value: 1 for active, 0 for inactive. Autotask normally expects the flag on a new item, so send 1 unless you deliberately want the asset filed as inactive. The update tool accepts the same flag, so you can retire an asset later by setting it to 0.

Approval and Preview

All 11 tools that change Autotask data ask for approval before they run. They can also be previewed rather than executed, so you can see exactly what an agent intends to do before it does it. A previewed call is marked as a preview in the run’s activity timeline and in its audit. See The Agent node for how approval behaves inside a workflow, and the AI Playground for trying a prompt against Autotask before you build anything.

If you are still having trouble, we’re here to help! Submit a ticket here for assistance, and don’t forget to check our status page to ensure there are no outages in your area.