Skip to content
English
More support Customer portal
Contact us
  • There are no suggestions because the search field is empty.

Party Has Changed to Client During the Request Lifecycle

Overview

During the lifecycle of an Intapp Request, a Party record may unexpectedly change status and become a Client record. When this happens, the Request may error and highlight the Party as “Not found”. This typically occurs due to changes in the practice management system (e.g., 3E) or updates to Party classifications mid‑workflow.

This article explains how to identify the issue and the recommended steps to resolve it.

Symptoms

Users may observe:

  • An error message within the Request indicating that a Party is “Not found.”
  • The Party highlighted within the Request UI as problematic.
  • When scrolling to the top of the Request, the Party Name matches the Client Name, indicating that the Party record has been replaced or reclassified.

These symptoms suggest that the Party has been converted or updated to a Client in the firm's master data system.

Why It Happens

This issue usually occurs when:

  • The Party was originally added as a non‑client entity (e.g., prospect, counter‑party, contact).
  • The same entity was later converted to a Client in the master system (e.g., during onboarding).
  • The associated Request still references the original Party record, which no longer exists in its original state.

As a result, the Request cannot resolve the Party record, and an error is triggered.

How to Fix the Issue

Resolution typically requires updating the Request to reference the correct, newly created Client record.

Step 1 — Identify the Problematic Party

  1. Open the Request.
  2. Click into the error message to locate the Party flagged as “Not found.”
  3. Review the Party grid — you will likely see that the Party Name now matches the Client Name.

Step 2 — Review How the Party Changed

Confirm whether the entity was converted to a Client in the PMS.
If so, the Request must be updated to reference the new Client record.

Step 3 — Apply the Correct Fix

Depending on how the Request is configured at your firm, common fixes include:

  • Removing and re‑adding the Party using the new Client record
  • Refreshing or re‑syncing Party details
  • Updating internal mappings where custom logic is used
  • Ensuring the workflow is pointing to the correct Client identifier

Step 4 — Consult a Developer (If Required)

If the Request uses custom logic, custom Party mappings, or special workflow rules, consult a developer familiar with the client environment before applying changes.

This is especially important where custom validations or integrations may be impacted.

Best Practices

  • Avoid changing Party classifications mid‑Request where possible.
  • If a Party is expected to become a Client during workflow progression, confirm the system supports dynamic updates.
  • Refresh Party data when a record changes state in the PMS.
  • Train users to re‑select the updated Client record when needed.