Preserving the Original Assignee on a Pylon Issue

Overview

Out of the box, Pylon's "Assignee" field always reflects the current assignee on an issue. If an issue is reassigned (manually, via round-robin, or through an escalation), the original assignee is lost from the field — you'd have to dig through the activity log to recover it.

This guide walks through a setup that automatically captures the very first assignee on an issue and stores it in a custom field called Original Assignee. Once captured, this value never changes, even if the issue is reassigned later. This is useful for:

• Reporting on who originally picked up an issue versus who closed it

• Attribution and credit for first-touch response

• Coaching and QA workflows where you want to know who initially handled the case

• SLA reporting tied to the first responder

The workflow has four parts:

1. Create a custom Original Assignee text field on issues.

2. Create an API key that the webhook will authenticate with.

3. Create a webhook that PATCHes the issue and sets Original Assignee.

4. Build an assignment trigger that fires the webhook only on the first assignment.

You only need to do this once — after that, every newly assigned issue will be stamped automatically.

Step 1 — Create the "Original Assignee" custom issue field

1. In Pylon, open "Issue data" in settings.

2. Click Create Field and choose "Text". Name the field Original Assignee and include a description if you want.

   1. If you choose to name the field something different, take note of the API slug as you'll need to make some edits in Step 3 when you configure the webhook.

Step 2 — Create an API token for the webhook

The webhook will authenticate to Pylon's REST API as a service account. You need an API key with permission to update issues.

1. Go to Settings → API Tokens.

2. Click the Create button, name it something descriptive (like Original Assignee Webhook), and assign it a role like Member so it has permission to write to issues. If you want it to be scoped more tightly, you can create a Custom Role (like "API Issue Write") that only has access to issues.

3. Copy the key immediately — Pylon shows it exactly once. We recommend storing it in a password manager if available, but make sure to

Step 3 — Create the webhook

The webhook is a small piece of automation that takes the assignee data from a trigger and sends a PATCH request to the Pylon Issues API.

Trigger action config:

Method: PATCH

Target URL (copy and paste this directly, otherwise the issue ID variable won't work as expected):

https://api.usepylon.com/issues/{{ issue.id }}

Headers (replace YOUR_KEY_HERE with the key from Step 2):

Authorization: Bearer YOUR_KEY_HERE

Body:

json

{
  "custom_fields": {
    "original_assignee": "{{assignee.name}}"
  }
}

This is the piece that fires the webhook the moment an issue is assigned for the first time.

Step 4 — Set up the trigger

1. Go to Settings → Triggers

2. Click Create Trigger

Configure the trigger:

• WHEN Issue Assigned

• IF Original Assignee has no value

• THEN Send Webhook

• URL: the Zapier hook URL from Step 3 (or your self-hosted endpoint).

• Method: POST

• Headers: none required for Zapier; if you used a self-hosted endpoint, add whatever auth you set up.

• Body:

  {
    "custom_fields": [
      {
        "slug": "original_assignee",
        "value": "{{ issue.assignee.first_name }} {{ issue.assignee.last_name }}"
      }
    ]
  }

Testing the full flow

1. Create a new test issue in Pylon.

2. Assign it to yourself.

3. Within a few seconds, refresh the issue. The Original Assignee field should now show your email.

4. Reassign the issue to a different teammate. Assignee updates; Original Assignee stays put — exactly what we want.

5. Check Settings → Triggers → View Logs to confirm the webhook fired once and skipped the second assignment.