Incident relationship based on fields value

Question

Hello everyone,

I am currently working on an automation use case in SWSD and would like to know if the following scenario is possible or if there are recommended best practices.

Use case:

We want to automatically create a relationship between two incidents based on matching field values.

Example:

Incident X contains field: Employee Full Name

Incident Y contains field: Employee Name

If the values match, we want to automatically:

identify Incident Y

and create a relationship/link between Incident X and Incident Y.

Both type of incidents must be created manually.

Question:

Is it possible to achieve this logic directly in SWSD (via Process Integration, workflow rules, or API configuration)?

Or would this require external processing?

Any guidance, examples, or best practices would be highly appreciated.

Thank you in advance.

Siviu_iBO · Answer

Hello and thank you for the reply.

The main issue I currently have is understanding how to properly search for Incident Type X records where the text field "Employee Full Name" matches the value from Incident Type Y field "Employee Name" (user type field).

I attempted to use a GET query with category/subcategory and custom field filters, but it appears the custom field filtering is either ignored or also returns the current incident itself.

And second, this cannot be done in an Automation Rule because the custom field Employee Name does not provide the [Not Set] option in the condition builder. This is achievable in a Process within a Service Request.

Could you please clarify if matching/filtering by custom field values in this scenario is officially supported in SWSD Process Integration/API queries, especially when comparing a text field against a user-type field?

Thank you.

muhammad.osama · Answer

This is a classic "advanced automation" request in SolarWinds Service Desk (SWSD). Because the native Workflow engine is primarily built for sequential tasks and basic field updates, performing a cross-record lookup and relationship linking requires a more strategic approach.

You are correct that this isn't a "one-click" native checkbox, but it is absolutely achievable within the platform using Process Integration or the SWSD API.

The Recommended Approach: Process Integration

The most efficient way to do this without external middleware (like Zapier or Power Automate) is to use a Workflow Rule combined with a Process Integration step that calls the SWSD API back onto itself.

1. Setup the Trigger (Workflow Rule)

* Trigger: Set the rule to fire when an Incident is created or updated.
* Condition: Ensure the "Employee Name" field is not empty.
* Action: Trigger a Process Integration (a "Web Hook" to the SWSD API).

2. The Logic (The API Call)

The logic requires two specific API steps:

* GET: Search for existing incidents where CustomField_EmployeeName matches the value of the current incident.
* POST: Use the Incident ID from the result of step 1 to create a relationship.

The Relationship API endpoint:POST /incidents/{{current_incident_id}}/related_incidents.jsonPayload: { "related_incident_id": "{{matching_incident_id}}" }

Best Practices & Practical Tips

* Avoid the "Infinite Loop": When Incident X links to Incident Y, and Incident Y is updated, it might try to link back to Incident X. Add a condition in your workflow: If Related Incidents is Empty.
* Handle Multiple Matches: If your search returns three incidents for "John Doe," your automation needs to decide: link to the most recent one, or link to all three? (Linking to the most recent is usually the safest "Operational Story").
* Normalization: Since you are matching "Employee Full Name" to "Employee Name," ensure your staff are trained on formatting. API searches are often case-sensitive; "John Doe" may not match "john doe."
* The "Evidence" View: Once linked, these incidents will appear in the Related Items tab. This perfectly supports your philosophy: the technician now has the Evidence of a recurring issue for this specific employee as part of the current ticket's State.

Can this be done 100% Natively?

Technically, no. You cannot "Search" other records using a standard Workflow "Update Field" action. You must use the API (via Process Integration) to perform the "lookup" phase of your request.