AutoTask LCP

[TimWheeler-SQUP]

🔌 Plugin overview

• Plugin name: AutoTask
• Purpose / problem solved: Enable SquaredUp users to monitor tickets, contracts, projects, companies, contacts, and resources via Autotask PSA
• Primary audience (e.g. platform teams, SREs, product teams): MSPs and IT service teams using Autotask for PSA/ticketing
• **Authentication method - API username and secret (API user credentials)

---

🖼️ Plugin screenshots

---

🧪 Testing

Tested all data streams return results. Status and state mappings validated for tickets, contracts, and projects. OOB tickets dashboard loads and displays data correctly. Object indexing confirmed for companies, contacts, contracts, projects, and resources.

---

⚠️ Known limitations

None at this time.

---

📚 Checklist

• Plugin, datastream and UI naming follow SquaredUp guidelines
• Logo added
• One or more dashboards added
• README added including configuration guidance
• No secrets or credentials included
• I agree to the Code of Conduct

[github-actions]

🧩 Plugin PR Summary

📦 Modified Plugins

• plugins/AutoTask/v1

📋 Results

Step	Status
Validation	✅ Passed
Deployment	🚀 Deployed

🔍 Validation Details

✅ auto-task

{
  "valid": true,
  "pluginName": "auto-task",
  "pluginType": "cloud",
  "summary": {
    "Data Streams": 11,
    "Import Definitions": 1,
    "UI Configuration": true,
    "Has Icon": true,
    "Has Default Content": true,
    "Config Validation": true,
    "Custom Types": true
  }
}

[claude]

🔴 Three columns in the Tickets data stream reference field names that do not exist on the AutoTask API response, so they (and their dependent name-resolution columns) will always be blank: firstresponeassignedresourceID (line 51) is a typo (respone → response) and the field does not exist anyway — the real one is firstResponseInitiatingResourceID (already mapped on line 79); LastActivityResourceID (line 53) and CreatorResourceID (line 58) are PascalCase but AutoTask returns these as lowerCamelCase lastActivityResourceID / creatorResourceID. Fix the casing and either drop the typoed column or repoint it at firstResponseInitiatingResourceID so the First Response Resource, Last Activity Resource, and Creator columns are not empty in the shipped dashboard.

Extended reasoning...

What is wrong

Three metadata entries in plugins/AutoTask/v1/dataStreams/tickets.json reference field names that do not match the keys returned by the AutoTask Tickets REST API. JSON property matching is case-sensitive, so an entry whose name does not exactly match a key in the payload binds to nothing — the column ends up empty, and any companion column that uses it via sourceId for object resolution also resolves to empty.

The three offenders:

1. Line 51 — "name": "firstresponeassignedresourceID". Two problems: (a) the literal typo (respone is missing the s of response), and (b) even spelled correctly, the AutoTask Tickets entity has no firstResponseAssignedResourceID field. The real field for "who handled first response" is firstResponseInitiatingResourceID, which is already mapped (as a hidden ID-only column) on line 79. So the First Response Resource column on line 52, which does "sourceId": "firstresponeassignedresourceID", will never resolve.
2. Line 53 — "name": "LastActivityResourceID". AutoTask returns this as lastActivityResourceID (lowercase first letter — see every neighbouring field in this same file: assignedResourceID, completedByResourceID, companyID, contactID, contractID, and the correctly-cased firstResponseInitiatingResourceID on line 79).
3. Line 58 — "name": "CreatorResourceID". Same issue: AutoTask returns creatorResourceID.

Why existing code does not save it

The trailing { "pattern": ".*", "visible": false } catch-all does pick up the actual lowercase keys from the payload — but it adds them as hidden columns under their real names (lastActivityResourceID, creatorResourceID). The explicitly-declared PascalCase entries remain attached to nothing, and the dependent name-lookup columns (lastActivityResourceName, creatorResourceName, firstResponseAssignedResourceName) reference the explicit (broken) sourceIds, not the catch-all ones — so the visible Last Activity Resource, Creator, and First Response Resource columns ship blank.

Step-by-step proof for LastActivityResourceID

1. AutoTask GET /Tickets/query returns each ticket containing "lastActivityResourceID": 12345 (lowercase l).
2. The metadata column { "name": "LastActivityResourceID", … } (uppercase L) tries to read payload.LastActivityResourceID — JavaScript object access is case-sensitive, so this is undefined.
3. The next column { "name": "lastActivityResourceName", "sourceId": "LastActivityResourceID", … } then tries to look up the resource object by the value of LastActivityResourceID, which is undefined, so the cell is blank.
4. Meanwhile the catch-all { "pattern": ".*" } does pick up the real lastActivityResourceID key — but as visible: false and with no sourceType/sourceId wiring, so it never resolves to a name.

Result: a user loading the bundled Tickets Overview dashboard sees Last Activity Resource, Creator, and First Response Resource always empty.

How to fix

• Line 51–52: either delete both lines, or rename to firstResponseInitiatingResourceID (and remove the now-redundant hidden ID-only mapping on line 79).
• Line 53: rename LastActivityResourceID → lastActivityResourceID (and update the sourceId on line 54 to match).
• Line 58: rename CreatorResourceID → creatorResourceID (and update the sourceId on line 59 to match).

[claude]

🟡 metadata.json polish issues per the repo plugin guidelines: (1) the description on line 8 is missing a trailing period; (2) category: "User Defined" on line 9 is the export-wizard placeholder — guidelines say to reuse an existing category (e.g. Issue Tracking matching Rootly, since AutoTask is a PSA/ITSM tool); (3) the links array only has the source link — guidelines say to also include a documentation link to the bundled docs/README.md.

Extended reasoning...

The repo plugin authoring guidelines (see CLAUDE.local.md and the in-repo plugin review prompt) call out three specific things about metadata.json that are not followed in plugins/AutoTask/v1/metadata.json:

1. Description missing trailing period (line 8)

The guideline states: "description … Should always be appropriately punctuated, e.g. ending with a full stop." The current value is:

"description": "Monitor tickets, contracts, projects, resources, and company data from AutoTask PSA"

Note there is no closing period. Fix: append . so it reads "…from AutoTask PSA.".

2. Category User Defined is the export-wizard placeholder (line 9)

Guideline: "category — Mandatory. Reuse an existing category from other plugins where possible." A scan of the other plugin metadata files in this repo shows no other plugin uses User Defined; it is the default value the export wizard puts in when the author has not picked one. Existing categories that already appear in this repo include Issue Tracking (Rootly), Monitoring (DattoRMM, Phare, UptimeRobot, SumoLogic), Database, Network, Security, Utility, Collaboration, Fun. AutoTask is a PSA/ITSM ticketing product — the description even says "AutoTask PSA" — so Issue Tracking (matching Rootly) is the natural fit. Monitoring would also be defensible.

3. Missing documentation link (lines 40–46)

Guideline: "links — Should typically contain two links, one link with category: source linking to the GitHub repository, and another link with category: documentation linking to the markdown documentation in the repository." This PR ships plugins/AutoTask/v1/docs/README.md (a useful onboarding doc covering the API user setup and zone URL), but the links array only has the source entry. Other plugins (e.g. DattoRMM) include both. The example in CLAUDE.local.md even shows the exact pattern.

Step-by-step proof

1. Open plugins/AutoTask/v1/metadata.json (lines 8–9): "description": "Monitor tickets, contracts, projects, resources, and company data from AutoTask PSA", then "category": "User Defined",. The description has no .; the category is the placeholder string.
2. Search the repo for other usages of "category": "User Defined" in any plugin metadata.json — there are none, confirming this is not an established category.
3. Search the repo for plugins that use both a source and a documentation link — multiple do (e.g. DattoRMM), matching the guideline. AutoTask only has source (lines 40–46).
4. plugins/AutoTask/v1/docs/README.md exists in this same PR, so the documentation link target is already in place.

Suggested fix (drop-in)

"description": "Monitor tickets, contracts, projects, resources, and company data from AutoTask PSA.",
"category": "Issue Tracking",
…
"links": [
    { "category": "documentation", "url": "https://github.com/squaredup/plugins/blob/main/plugins/AutoTask/v1/docs/README.md", "label": "Help adding this plugin" },
    { "category": "source", "url": "https://github.com/squaredup/plugins/tree/main/plugins/AutoTask", "label": "Repository" }
]

Each item is individually a nit, but bundled they're a quick polish pass that brings the plugin in line with the repo's stated catalog conventions before publish.

[claude]

🟡 Two files unrelated to the AutoTask plugin appear to have been committed accidentally: test-present.txt at the repo root contains only the literal word test and looks like a sanity-check artifact, and CLAUDE.local.md claims in its own body that *.local.md is gitignored but .gitignore only excludes *.local.json, so the file slipped through. Either delete both files from the PR, or update .gitignore to add *.local.md and remove the file.

Extended reasoning...

What the bug is

Two files at the repository root appear to have been added unintentionally and are not part of the AutoTask plugin being delivered.

1. test-present.txt

This file lives at the repo root (not under plugins/AutoTask/v1/) and contains only the literal text test (no trailing newline). The filename and content are characteristic of a sanity-check artifact — it has no role in the AutoTask plugin, is not referenced anywhere, and does not affect functionality. It is simply noise that should not ship.

2. CLAUDE.local.md

This is a 415-line "Local Reference" document for the plugin author. The file itself states (line 184):

*.local.json and *.local.md are gitignored in this repo

…but the repo's .gitignore only contains *.local.json (line 81). There is no *.local.md pattern, so the .local.md claim is false and this file was committed against the author's apparent intent. The .local infix in the filename, plus the file's content (internal Confluence URLs at squaredup-eng.atlassian.net, internal repo paths, raw squaredup CLI commands, author scratch notes), all signal it was meant to live only on the author's machine.

Step-by-step proof

1. Open .gitignore at the repo root → search for local. The only matching line is *.local.json. There is no *.local.md entry.
2. Open CLAUDE.local.md and look at line 184 → the file claims *.local.json and *.local.md are both gitignored. This contradicts step 1.
3. Run git ls-files | grep -E '(test-present|CLAUDE\.local)' on the PR branch → both files appear as tracked, confirming they were committed.
4. Open test-present.txt → contents are exactly test (4 bytes, no newline — see the diff's \ No newline at end of file marker). It is referenced nowhere else in the diff or the plugin folder.

Why existing safeguards didn't catch this

The plugin validation pipeline (per the github-actions PR comment) only validates files under plugins/AutoTask/v1, so root-level stray files don't trip it. The .gitignore doesn't have *.local.md and .txt is also not gitignored, so git add happily picked them up.

Impact

No runtime impact, but:

• test-present.txt is unrelated noise at the repo root that future contributors will wonder about.
• CLAUDE.local.md exposes internal Atlassian/Confluence URLs and contributor-only workflow notes in a public plugin repo, and its own statement about being gitignored is now demonstrably false — confusing for any reader.

How to fix

Pick one (the conservative option is the first):

1. Remove both files from the PR: git rm test-present.txt CLAUDE.local.md and re-commit. This is the simplest fix and matches the apparent intent of the .local filename.
2. Or, if CLAUDE.local.md is meant as a contributor doc, rename it (e.g. to docs/PLUGIN_AUTHORING.md) and either delete the inaccurate gitignored-claim line or correct it.
3. Or, add *.local.md to .gitignore and git rm --cached CLAUDE.local.md so the file's own claim becomes true going forward — and still delete test-present.txt.

Severity: nit — neither file affects plugin functionality, but both should be cleaned up before merge to avoid shipping unrelated noise and contradictory documentation.

[claude]

🟡 The product is officially branded "Autotask" (one capital A), not "AutoTask" — see Datto/Kaseya's product pages for "Datto Autotask PSA". Per the repo guideline (displayName should use the correctly styled/cased official product name, e.g. SharePoint NOT sharepoint), update user-visible strings throughout the plugin: metadata.json displayName and description, custom_types.json name entries (e.g. "AutoTask Company" → "Autotask Company"), docs/README.md headings/body, ui.json help text, and configValidation.json success/error messages. Internal identifiers (name: "auto-task", sourceType: autotask-*) can stay as-is.

Extended reasoning...

The bug\n\nThe plugin styles the product name as "AutoTask" (camelCase, two capitals) throughout user-facing strings. The official Datto/Kaseya brand spelling is "Autotask" — one word, only the leading A capitalized — as used consistently on Kaseya/Datto product pages, support docs, and historical Datto materials (now branded "Datto Autotask PSA" or "Kaseya Autotask PSA").\n\nWhy the repo guidelines apply here\n\nThe authoring guidelines (CLAUDE.local.md) explicitly call this out: "displayName — Use the correctly styled/cased official product name for display names, e.g. SharePoint NOT sharepoint." That same principle covers any user-visible reference to the product's brand name, not just the one field — README headings, configValidation messages, and ui.json help text are all surfaces a user reads.\n\nWhere it appears in this PR\n\n- plugins/AutoTask/v1/metadata.json line 3: "displayName": "AutoTask" and line 8: "description": "...from AutoTask PSA"\n- plugins/AutoTask/v1/custom_types.json: every name field ("AutoTask Company", "AutoTask Contact", "AutoTask Project", "AutoTask Resource", "AutoTask Contract")\n- plugins/AutoTask/v1/configValidation.json: the displayName ("AutoTask connection"), success ("Successfully connected to AutoTask"), and error ("Cannot connect to AutoTask…") strings\n- plugins/AutoTask/v1/docs/README.md: multiple references including "You will need an AutoTask account…", "Log in to AutoTask…", "Your Zone URL is based on the AutoTask data centre…"\n- plugins/AutoTask/v1/ui.json: help text such as "Your AutoTask zone URL…", "The email address of your AutoTask API User", "Generated when creating an API User in AutoTask"\n- plugins/AutoTask/v1/dataStreams/companies.json: description: "All active companies in AutoTask"\n\nStep-by-step proof\n\n1. Open Kaseya's product page or any Datto support article for the PSA product — the brand is consistently "Autotask" / "Datto Autotask PSA".\n2. Open this PR's metadata.json, line 3 — "displayName": "AutoTask" (camelCase T).\n3. Open the repo authoring guidelines — they require correctly styled/cased official product names.\n4. The two strings differ in capitalization, so the displayName (and the other user-facing strings listed above) violate the guideline.\n\nImpact\n\nUser-visible: in the catalog, plugin install screen, configuration validation messages, README, and global search/drilldown labels for indexed objects ("AutoTask Company" etc.), the product is mis-styled. Functionally harmless, but inconsistent with the official brand and the repo's own conventions.\n\nFix\n\nReplace "AutoTask" with "Autotask" in every user-visible string listed above. Internal identifiers (name: "auto-task", sourceType: autotask-*, the AutoTask folder name, custom_types sourceType values) do not need to change — only display strings users see.