Skip to main content

Troubleshooting "Incompatible State Types for Assignment" in InRule for Dynamics CRM

Symptom​

Running a rule via the InRule plugin for Dynamics CRM against certain records fails with:

System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]:
Error returned from rule service : Incompatible state types for assignment.

This is often intermittent by data set: manually created records execute successfully, while records loaded through a data migration consistently fail with the same rule.

Cause​

InRule's entity binding for Dynamics CRM assumes that each entity record's unique identifier (GUID) is globally unique across the organization's dataset, not merely unique within a single table. If a data migration or load process assigns the same GUID value to records in two different CRM tables (each locally unique within its own table, but colliding across tables), InRule can resolve the wrong entity or state type during field assignment, producing this exception.

This is a common risk with migrations from legacy systems that generated per-table sequential or reused identifiers, since Dynamics itself does not require GUIDs to be unique across tables, only within one.

Diagnosis steps​

  1. Confirm the failure is data-dependent: does the same rule succeed against manually created records and fail only against migrated records?
  2. Compare a failing migrated record against a working manually created record, focusing on:
    • Option set / state mismatches
    • Unexpected null values
    • Lookup/reference inconsistencies
    • String vs. numeric/date type mismatches
  3. Check whether any GUID value used as a record identifier in the affected table also appears as the identifier for a different record in another table in the migrated dataset. Duplicate GUIDs across tables are the confirmed root cause for this specific exception.

Resolution​

Correct the data migration or load process so that every generated GUID is globally unique across all tables in the dataset (for example, always generate new GUIDs via the platform rather than reusing or deterministically deriving them per table). Re-run the migration or load for affected records, then retest the rule.