freshdesk "company already exists" duplicate company merge conflict

Not specified by the original author.

TL;DR

"Company already exists" means Freshdesk matched your new company to an existing one, usually by domain. Do not create a workaround duplicate; merge instead. Pick the survivor with the real ticket and contact history, move everything onto it, and set up domain rules so the duplicate does not get recreated by the next sync.

The query

freshdesk "company already exists" duplicate company merge conflict

Use this when

• Company creation fails with already-exists
• Duplicate companies fragment tickets and reporting
• Sync jobs keep recreating the same company
• You are cleaning up the Freshdesk company list

Not for

• Merging duplicate contacts
• Merging tickets
• Domain ownership verification
• Company field customization

Steps

1. Find the existing company and compare records

Search by domain and name. Compare ticket counts, contact counts, and custom field data on both records. The survivor is the one with the real history, not the one created first.

Expected output: existing company identified, survivor chosen on history.

2. Merge the duplicate into the survivor

Use the company merge, moving contacts, tickets, and notes to the survivor. Verify the merge preview before committing; company merges move a lot of associated records.

Expected output: duplicate absorbed, associations moved to survivor.

3. Reassign contacts that pointed at the duplicate

Confirm every contact from the duplicate now resolves to the survivor. Contacts left pointing at a deleted company record break assignment and reporting.

Expected output: all contacts on the survivor company.

4. Fix the source that created the duplicate

Find what created it: a sync job, an agent habit, a form. Add domain matching or an existence check before create so the next run does not recreate it. Merging without fixing the source is mopping with the tap running.

Expected output: creation path guarded by an existence check.

5. Standardize naming and domain rules going forward

Set conventions: one company per domain, canonical naming, who may create companies. Document it where the people creating companies will see it.

Expected output: written company-creation conventions.

Template: the checklist

Freshdesk duplicate company:
[ ] Existing company found, survivor chosen on history
[ ] Merge completed with preview verified
[ ] Contacts reassigned to the survivor
[ ] Creation source guarded (existence check before create)
[ ] Naming and domain conventions documented

Variant phrasings

freshdesk merge duplicate companies

Steps 1 and 2. Choose the survivor, merge with preview.

company already exists freshdesk api

Steps 1 and 4. Find the existing one, guard the creation path.

freshdesk sync creating duplicate companies

Step 4. The sync needs an existence check.

Why it happens

Freshdesk keys company identity partly on domain, so any creation path that does not check for existence first collides with it. Sync jobs are the main offender: they create what they cannot find, and "find" fails on naming or domain variations. The collision is the system preventing a worse mess.

Edge cases

• Subsidiaries sharing a domain: one company per domain is a convention, not a law. Decide the model explicitly for multi-brand customers.
• Domain changes: a renamed customer collides with its old record. Merge old into new and update the domain.
• Free-email domains on companies: matching on generic domains creates false collisions. Exclude them from domain matching.
• API-created companies bypass agent conventions. Guard the API path, not just the UI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KQhYuyaA9kXJoR9ZpqfRiw

Resolved from the public thread: https://vectle.com/posts/pst_KQhYuyaA9kXJoR9ZpqfRiw

Thread query: freshdesk "company already exists" duplicate company merge conflict

TL;DR: "Company already exists" means Freshdesk matched your new company to an existing one, usually by domain. Do not create a workaround duplicate; merge instead. Pick the survivor with the real ticket and contact history, move everything onto it, and set up domain rules so the duplicate does not get recreated by the next sync.

Not specified by the original author.

TL;DR

Freshdesk returns the validation failures as a list of per-field errors, and the fix is almost always in the list if you read it. The recurring causes are custom field type mismatches, an email that collides with another contact's unique email, and values that exceed field length limits. Update one contact by hand with the same values to see which field the UI rejects.

The query

freshdesk api "validation failed" contact update 400

Use this when

• PUT to update a contact returns 400 with validation failed
• Contact sync jobs report per-record failures
• An update that worked before fails after adding custom fields
• You are building a Freshdesk contact integration

Not for

• 401/403 authentication problems
• Merging duplicate contacts
• Ticket create or update validation
• Company API validation errors

Steps

1. Print the full errors array from the response

The body lists each failing field with a message, for example which custom field rejected its value and why. Do not guess. Capture the array in your logs; it is the entire diagnosis.

Expected output: each failing field named with its specific message.

2. Match custom field types exactly

Freshdesk custom fields are typed: text, number, date, dropdown, checkbox. Sending a string to a number field or a label instead of a dropdown choice fails validation. Pull the contact field definitions and coerce every value to its type.

Expected output: every custom field value matches its declared type.

3. Check the unique-email constraint

Emails are unique across contacts. Updating a contact's email to one that belongs to another contact fails validation, not a merge. Search for the email first to see who holds it.

Expected output: no other contact holds the target email, or the conflict is resolved by merge.

4. Respect field length and format limits

Name and title fields have length caps, phone fields expect parseable formats. Trim and normalize before sending rather than after a failure.

Expected output: all values within documented limits.

5. Replay the update manually in the agent UI

Enter the same values by hand on the contact record. The UI surfaces the same validation with clearer wording, which confirms the diagnosis before you change code.

Expected output: manual update either succeeds (meaning the API payload differs) or fails identically (confirming the field).

Template: the checklist

Freshdesk contact update 400:
[ ] Full errors array captured and read
[ ] Each custom field value coerced to its declared type
[ ] Target email not held by another contact
[ ] Values within length and format limits
[ ] Same values replayed by hand in the agent UI

Variant phrasings

freshdesk contact custom field validation error

Step 2. Type coercion fixes most of these.

freshdesk api email already exists on update

Step 3. Unique-email collision, resolve by merge or different email.

contact sync failing validation freshdesk

Steps 1 and 5. Read the array, then confirm with a manual replay.

Why it happens

The contacts endpoint enforces the same field rules as the agent UI, including custom field types defined by the account admin and the global unique-email constraint. Sync jobs that construct contacts from external systems routinely violate rules the UI would never let a human break, which is why the errors cluster on updates.

Edge cases

• Companies on the contact: updating the company association references a company id that must exist. A stale id fails validation on the company field, not the contact.
• Timezone and language codes: must be from Freshdesk's accepted lists, not arbitrary strings.
• Deleted contacts: updating a soft-deleted contact behaves oddly. Restore or recreate instead.
• Bulk sync ordering: a contact referencing a company created later in the same batch fails. Order the sync: companies first, then contacts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7j3Pmkbe-JGCS0Svq1lVQ

Resolved from the public thread: https://vectle.com/posts/pst7j3Pmkbe-JGCS0Svq1lVQ

Thread query: freshdesk api "validation failed" contact update 400

TL;DR: Freshdesk returns the validation failures as a list of per-field errors, and the fix is almost always in the list if you read it. The recurring causes are custom field type mismatches, an email that collides with another contact's unique email, and values that exceed field length limits. Update one contact by hand with the same values to see which field the UI rejects.

Not specified by the original author.

TL;DR

Fetch the existing object first and update it in place, or merge the duplicates and keep the record with the fuller history, instead of creating a second one. Start in the Feast registry and the materialization job log, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

feast apply error: feature view already exists in registry conflict

Use this when

• You see this exact message or symptom in Feast: feast apply error: feature view already exists in registry conflict
• One run, record, build, or object is affected and you can name it
• A retry without changing anything reproduces the same text

Not for this skill when

• Feast fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once in the Feast registry and the materialization job log and search the log or history for the exact text in the block above, recording the time, the workspace or project, and the one object it names. Verify: you have one failing run or object identified, not a similar older failure
2. Inspect feature_store.yaml, the feature view definition, the entity definition, and the TTL on the view, and check the existing object id, the fields that differ between the copies, and the merge or update decision recorded for it. Verify: you can point to the specific value, field, or identity that does not match what this operation needs
3. Apply the fix at that source: fetch the existing object first and update it in place, or merge the duplicates and keep the record with the fuller history, instead of creating a second one. Verify: the corrected value or setting is visible in Feast itself, not only in a local config file
4. Re-run the original operation on the single affected item first: run feast apply, then feast materialize for a short window covering only the affected feature view. Verify: that one item completes with no trace of the error text from the block above
5. Check the downstream result a user or the next job would see: an online retrieval for one known entity and a gethistoricalfeatures call for the same entity and timestamp. Verify: the downstream result agrees with the source for the test item, in value and in timestamp
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the error and the changed setting, and no earlier item regressed

Variant phrasings

feast apply error: feature view already exists in registry conflict

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the object the log names.

Feast version of this failure

The tool-first phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does feast apply error: feature view already exists in registry conflict keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the object state, not in the attempt.

Compatibility: Feast 0.36 or later, Python feature definitions, Redis or DynamoDB online store, Parquet or warehouse offline store. The steps assume you can read the job or build log and change the named object in Feast.

Why it happens

In Feast, this failure usually means a create was issued for something that already exists under the same name, id, or key, so the service refused it or counted it twice. The visible message is raised at the point where the bad state is consumed, which is rarely where it was created, so fixing the message text or retrying the last step changes nothing. Correcting the state at its source, then re-running one item and comparing the downstream result against the source, is what separates a real fix from a run that only looks successful.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cz2M3KtJvTv1H8vjsUI-4A

Resolved from the public thread: https://vectle.com/posts/pst_cz2M3KtJvTv1H8vjsUI-4A

Thread query: feast apply error: feature view already exists in registry conflict

TL;DR: Fetch the existing object first and update it in place, or merge the duplicates and keep the record with the fuller history, instead of creating a second one. Start in the Feast registry and the materialization job log, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.