Use of CRM Destination Component

The CRM Destination Component is an SSIS data flow pipeline component that can be used to write data to a destination Microsoft Dynamics CRM server. You may create, updatedeleteupsert (Update / Insert), convert, merge, or ExecuteWorkflow CRM records using the CRM Destination Component. 

The CRM Destination Component includes the following three pages to configure how you want to write data to Microsoft Dynamics CRM server.

  • General
  • Columns
  • Error Handling

The General page is used to specify general settings for the CRM destination component. The Columns page allows you to map the columns from upstream components to CRM fields in the destination entity. The Error Handling page allows you to specify how errors should be handled when they occur. 

General page

The General page of the CRM Destination Component allows you to specify general settings for the component. 

CRM Destination Editor

CRM Connection Manager

The CRM destination component requires a CRM connection in order to connect with the Microsoft Dynamics CRM server. The CRM Connection Manager option will show all DynamicsCRM connection managers that have been created in the current SSIS package.

Action

The Action option allows you to specify how data should be written to the Microsoft Dynamics CRM server. There are eight (8) action types available.

  • Create - Create new record(s) in CRM
  • Update - Update existing record(s) in CRM
  • Delete - Delete record(s) from CRM
  • Upsert - Update any existing record(s) in CRM if matching can be found, otherwise create a new record with the information from the upstream pipeline components. 
  • Convert (since v5.0) - Convert a CRM record. The following are the supported entities:
    • Lead - Qualify a lead by converting it to CRM account, contact and opportunity records
    • Opportunity - Convert an opportunity record to a quote
    • Quote - Convert a quote to a salesorder
    • Salesorder - Convert a salesorder to an invoice
    • Team (only applicable to CRM 2013 or later) - Convert an owner team to an access team
  • Merge (since v3.3) - Merge action takes two CRM records as its input and performs a CRM merge action on them by retaining one of them while retiring another one.

    Merge action is only possible with the following CRM entities:
    • account
    • contact
    • lead
    When Merge action is chosen, you must provide the following two input columns in order to merge a pair of CRM records:
    • targetid - the record that you would like to retain
    • subordinateid - the record that is going to be retired, in which case, the record itself will be deactivated and all child records will be re-parented underneath the retained record which is specified by the targetid input column
    Since v8.0 release, we added two new optional fields for Merge action:
    • CoalesceNonEmptyValues - specify a Boolean value to determine whether to coalesce non-empty value during the Merge operation.
    • PerformParentingChecks - specify a Boolean value to determine whether a parenting check is needed during the Merge operation. Set to Ture to check if the parent information is different for the two entity records, otherwise, False.
  • ExecuteWorkflow (since v3.0) - Execute CRM workflow or custom action for the selected CRM record(s)
  • Send (since v9.0) - Send CRM email(s).
  • BulkDelete (since v9.1) - Submit a bulk delete job that deletes selected records in bulk. This job runs asynchronously in the background without blocking other activities.
Destination Entity

The Destination Entity option allows you to specify which CRM entity to write data to. When an option is selected, the SSIS Integration Toolkit will retrieve a list of all available CRM entities from the selected CRM connection. Please note that the list will only include the entities where the specified user in the CRM connection manager has the proper write privileges. 

NOTE:  You may select a N:M (many-to-many) CRM relationship entity as the Destination Entity, in which case you use the Create action to create an association between two CRM records, and use the Delete to disassociate two records. When the Upsert action is used for a N:M relationship entity, the component will try to determine if an association already exists in the system. It will only create a new association if there is no existing relationship between the two CRM records. 

NOTE:  You can see a CRM entity called accessteammember, this is not a real CRM entity. It is a virtual entity that helps facilitate adding / removing users to a CRM access team. You can only use this entity against CRM 2013 or later, since access team is a new feature introduced in CRM 2013. Further details about how to use entity are covered later in this document.

Update Matching Criteria

The Update Matching Criteria option allows you to specify how the Update action determines whether a record already exists in the destination CRM system. The component supports two Matching Criteria. 

CRM Destination Editor

  1. Primary Key - The Primary Key option matches CRM records based on their GUID IDs of their primary keys. 
  2. Alternate Key - The Alternate Key option allows you to uniquely identify a record aside from the primary key. This criteria relies on the alternate key setup in CRM.
Upsert/Update Matching Criteria

The Upsert/Update Matching Criteria option allows you to specify how the Upsert action determines whether a record already exists in the destination CRM system. In the case when Update action is used, this option is used to specify how to find the matched records in CRM system to perform an update. The component supports the following four matching options when the Upsert action is selected. 

CRM Destination Editor

  1. Primary Key - The Primary Key option matches CRM records based on their GUID IDs of their primary keys. 
  2. CRM Duplicate Detection - The CRM Duplicate Detection option matches CRM records based on the CRM duplicate detection rules that have been setup in CRM.
  3. Manually Specify - The Manually Specify option allows you to choose a combination of CRM fields to be used for the Upsert matching criteria in order to determine whether a matching record exists in the CRM system. When the Manually Specify option is selected, you will see checkboxes next to the CRM fields in the grid on the Columns page.
  4. Alternate Key - The Alternate Key option allows you to uniquely identify a record aside from the primary key. This criteria relies on the alternate key setup in CRM.
Handling of Multiple Matches (since v3.0)

It is possible that Upsert action could find multiple matches in the target CRM system when CRM Duplicate Detection or Manually Specified options are used. The Handling of Multiple Matches option allows you to specify what action will be taken when such multiple matches are found. There are four options available.

  • Update All
    This is the default behavior of the version prior to v3.0
  • Update One
    The component will only update the first matching record
  • Ignore
    The source row will be ignored when multiple matches are found
  • Raise an error
    An exception will be reported when multiple matches are found
Remove Unresolvable References

The Remove Unresolvable References option specifies how to handle CRM lookup fields when the reference records are not available. When this option is checked, if a CRM lookup field refers to a CRM record that does not exist in the system, the CRM lookup field will be removed before the data is written to the CRM system. 

NOTE: We do not typically recommend using this option, since it will remain silent to any broken lookup references.

NOTE: The Remove Unresolvable References option is not available when the Action is Delete

Enable CRM Duplicate Detection

The Enable CRM Duplicate Detection option specifies whether CRM duplicate detection should be fired when writing data to Microsoft Dynamics CRM. 

NOTE: The Enable CRM Duplicate Detection option is not available when the Action is Delete

NOTE:  In order for the CRM Duplicate Detection option to take effect, you must setup proper duplicate detection rules for the target CRM entity in your CRM system. You must also enable duplicate detection, which is a system-wide configuration setting available in Settings -> Data Management -> Duplicate Detection Settings. 

NOTE:  There is a special behavior that you should be aware of if you want to use the Enable CRM Duplicate Detection option. CRM duplicate detection relies on a CRM Asynchronous service job called the Matchcode Update job, which is not a real-time job. For this reason, any records that have been recently (for example, the last couple of minutes) added or updated in the system, will not have matching code in the CRM system until the Matchcode Update job kicks in next time, which usually happens every few minutes. Therefore, the duplication detection would not take them into account. Due to the mentioned reason, we do not usually recommend relying on CRM duplicate detection on large data load processes. A better option would be using the Upsert action, and selecting a combination of manually-selected matching fields. This is a more reliable solution since it performs a real-time duplicate check during the data load. 

Ignore Null-Valued Fields (since v2.0)

The Ignore Null-Valued Fields option allows you to ignore any fields that have a null value. By ignoring a field, the null value will not be posted to the CRM server. This can help avoid the situation that you overwrite non-empty values with an empty value, if your requirement dictates so.

Ignore Unchanged Fields (since v2.0)

The Ignore Unchanged Fields option allows you to ignore any fields that have not been changed in the target CRM system. This feature is useful when your CRM system has workflows or plugins to be fired when certain field value changes. With this option selected, the CRM destination component will check the target CRM system and compare each field to see if there are any changes for them. The component will only post the fields that have actual changes. All unchanged fields will be skipped and therefore, not posted to CRM. This component can prevent firing unnecessary CRM workflows or plugins.

NOTE:  "Ignore Unchanged Fields" option does not apply to CRM partylist (activityparty) fields due to the fact that partylist fields store complex values which are not always practical to compare. This does not have any negative impacts to your data integrity or anything in that regard, the only side effect is, all partylist fields will be posted to CRM server regardless whether there is a change or not.

Change Flag Field(s) (since v7.0)

The Change Flag Field(s) option can be enabled when the 'Ignore Unchanged Fields' option is selected. It is used in special cases to help track or tag where the last change of the record was initiated. For instance, if the source of your SSIS data flow is coming from your ERP system, you can have an input value for this field as "ERP" (or your actual ERP application name, such as "AX", "NAV"), we will only write to this field if there are any changes to other fields, when the 'Ignore Unchanged Fields' option is selected. You can use semi-colon (;) character as the delimiter to create a list of fields for this purpose.

Remove Invalid Characters (since v7.0)

When enabled, the Remove Invalid Characters option will remove any invalid characters from the input which can avoid an XML exception when the components tries to construct the SOAP request to be sent to CRM server. Those invalid characters are usually not accepted by CRM server even posted.

Batch Size (since v3.0)

The Batch Size option allows you to specify how many records you want to submit to the CRM server at a time (each service call). The destination component will set a default batch size based on the version of your CRM server. If the component determines that the Bulk Data Load API is supported by your CRM server (CRM 2011 Update Rollup 12 or later), it will set the Batch Size to 200. Otherwise it will default to 1. Using a batch size greater than 1 can help improve your data load performance, particularly if you are using CRM online or if you have a high network latency between your CRM server and the computer from which you run the SSIS jobs or packages.

NOTE:   CRM Bulk Data Load API supports a maximum batch size of 1000. We generally recommend 250 or lower to avoid possible timeout errors (and potentially other errors as well). The maximum limit of the Batch Size can be overridden by setting the ExecuteMultipleMaxBatchSize parameter (which is however not recommended).

NOTE: When using the Bulk Data Load API, you may want to consider increasing your CRM connection manager's timeout parameter to accommodate the extra time that is required to process the number of requests at server side.

NOTE: When you use a Batch Size that is greater than 1 for a CRM Online instance, you want to be extra cautious about any potential parallel execution of SSIS data flow tasks that write to CRM server using bulk API simultaneously. There is a throttling setting on CRM Online server side, which prohibits more than 2 concurrent ExecuteMultipleRequest executions per CRM organization (ExecuteMultipleRequest is what we use behind the scene when a Batch Size is specified). In other words, you should not run more than two CRM destination components in parallel that write to CRM Online server simultaneously by using a Batch Size greater than 1. Note that this throttling limit may be lifted by raising a ticket request to CRM online support team, however such requests are always subject to approval by CRM online team.

NOTE: When using the Upsert or Update action, and CRM Duplicate Detection or Manually Specify as the matching criteria option, in case there are duplicates in the incoming rows within the same batch, it could potentially create duplicates in CRM system. There are two options to work around the situation. 

  • You can eliminate duplicates in your source.
  • Or you can set the destination component's Batch Size to 1, so the component would look up the record one at a time.
Enable Multithreaded Writing (since v9.0)

Since v9.0 release, we added support for the Multi-threading feature, which allows you perform multi-threading when writing data to CRM. To configure the Multi-threading feature, you can check the Enable Multithreaded Writing option in CRM Destination component. The default number is 16.

NOTE:   This option supports a maximum number of 100 threads when writing to CRM. We generally recommend 20 or lower to avoid potential server error. However, you can adjust this settings based on your environment in order to get the best performance.

NOTE:   When this option is enabled, the record order may not be maintained from the upstream pipeline component.

Send datetime values in UTC format (since v3.0)

The Send datetime values in UTC format option indicates whether datetime values should be submitted to CRM server in UTC format. This option will apply to all datetime fields when selected.

Execute Workflow Option (since v3.0)

The Execute Workflow Option allows you to specify which CRM workflow or custom action you want to fire for the CRM records.

NOTE: In order for a CRM workflow to be shown in the list, the workflow has to be activated (or published) with the "As an on-demand process" option selected in CRM.

NOTE: Since v7.0, we added support for CRM custom actions using the ExecuteWorkflow option.

Refresh CRM Metadata Button

By clicking the "Refresh CRM Metadata" button, the component will retrieve the latest metadata from the CRM server and update each field. This feature works by performing the following three actions.

  • Update any existing fields to the latest CRM metadata
  • Add any new CRM fields that have recently been created in the CRM system
  • Remove any CRM fields that have recently been deleted from the CRM system

After clicking this button, you will receive the following screen once the refresh is done.

Refresh Metadata

This button can be also useful if you want to change the destination component's Connection Manager, or even Destination Entity option without having to lose all existing mappings. In case you need to make such changes, you can first use the destination component's Advanced Editor window to change its Connection Manager, and/or Destination Entity option accordingly, then re-open the destination component using its standard editor window, and click the "Refresh CRM Metadata" button, which should update the component properly.

Map Unmapped Fields Button (since v3.0)

By clicking this button, the component will map any unmapped CRM fields by matching their names with the input columns from upstream components. This is useful when your source component has recently added more columns, in which case you can use this button to automatically establish the association between input columns and unmapped CRM fields.

After clicking this button, you will receive the following message.

Map Unmapped fields

Clear All Mappings Button (since v4.1)

By clicking this button, the component will reset all your mappings in the destination component.

Columns page

The Columns page of the CRM Destination Component allows you to map the columns from upstream components to CRM fields for the destination entity. 

In the Columns page, you would see a grid that contains six columns as shown below.

CRM Destination Editor

  • Input Column - You can select an input column from an upstream component for the corresponding CRM field.
  • Destination CRM Field - The CRM field that you are writing data. 
  • Text Lookup - This is a feature that we added since v2.0. This option is only available for CRM lookup fields. When this option is selected, the component can perform lookup based on a text value of the target entity. The text value is the value of the target entity's primary field. Depending on the software version that you are using, the component will have different behavior when duplicates are found in the lookup entity. 
    • In our v2.0 release, Text Lookup feature will report an error when the text values of the target entity have duplicates (the values have to be unique).
    • Between v3.0 and v4.1 releases (inclusively), uniqueness is not a requirement. When duplicates are encountered, the component will use the last record returned by the query against the target entity.
    • From v5.0 release, you can define how lookup duplicates are handled.
    For further information about how to use the Text Lookup feature, please refer to the Working with the Text Lookup Feature section below. 
  • Data Type - This column indicates the type of value for the current CRM field in CRM system. Typically, it is required to pass in the value using the format indicated in Data Type column, but there are three exceptions.
    • When working with CRM lookup fields, if you are using the Text Lookup feature, you would pass in a text (string) value as the input although the field's Data Type is uniqueidentifier.
    • CRM lookup type field (which usually ends with type or typecode such as owneridtype, objecttypecode, etc.) can take either integer values or a string values, although its Data Type is int, when SOAP 2011 service endpoint is used. When working with SOAP 2007 or 2006 service endpoint, you must pass in the entity's type code in integer format.
    • CRM OptionSet (or picklist) field can also take either integer values or a string values, although its Data Type is int.
  • Create - This column should only appear when the Upsert action is used. It indicates whether the field is applicable to a Create request for an Upsert action. When the field is not applicable to a Create request, the input value of this field will be ignored when we post the Create request to the CRM server.
  • Update - This column should also only appear when the Upsert action is used. It indicates whether the field is applicable to an Update request for an Upsert action. When the field is not applicable to an Update request, the input value of this field will be ignored when we post the Update request to the CRM server.
  • Unmap - This column can be used to unmap the field from the upstream input column, or otherwise it can be used to map the field to an upstream input column by matching its name if the field is not currently mapped.

When the Upsert action is selected in the General page, and the Upsert Matching Criteria option has been chosen as "Manually Specify", you will see a checkbox for each field listed in the grid. You may select one or more fields so their value(s) are used as matching criteria.

CRM Destination Editor

When the Upsert action is selected in the General page, you will see two more columns in the column mapping grid called Create and Update, they have a value of either Yes or No. What they indicate is whether the corresponding field is applicable to the specified action. When the field is not applicable to a particular action, the value for the field might be discarded before writing to the CRM. For instance, if the field is not applicable for Create, then the value will be ignored when the Upsert action tries to create a new CRM record. Likewise, if the field is not applicable for Update, the value will be ignored when the Upsert action tries to update existing CRM record(s). Note that this is a feature added in v1.1 SR1, so if you are using an earlier version of the toolkit, you may not see those two columns.

NOTE: To maximize the component's performance, it is not advised to select too many fields for the matching purpose.

NOTE: You should consider adding custom indexes to those manually specified matching fields that you have selected in CRM database to improve the performance for the matching query. 

Working with Text Lookup Feature

Since v2.0, we added support for the Text Lookup feature, which allows you to perform lookup based on the text values of the target entity. To configure the Text Lookup feature, you click the ellipse button in Text Lookup column which is available in the CRM destination component's mapping page. You will be presented with the following screen.

Text Lookup Screenshot

There are three options that you can choose to define how the lookup is performed.

  • Do not Use Text Lookup - This is the default option. When selected, you have to provide primary key values in GUID format as input for the lookup field.
  • Use Primary Field (All) - Using this option, the lookup will be performed based on the primary field(s) of the target entity/entities. In other words, the input of the lookup field should be the text values of the primary field for the target entity/entities. From customization perspective, every CRM entity has a primary field. For instance, account entity's primary field is name, contact entity's primary field is fullname, and so on. So in the case when the lookup field is targeting account entity, you can provide a text value of "ABC Company" as the input, the component will perform a search by looking up "ABC Company" from the account entity and convert it into GUID as the input value for the lookup field.
  • Choose Target Field(s) - Using this option, you can specifically choose which text field should be used for the lookup purpose. When you choose this option, you will be presented with a list of the target entities for the lookup field, and you can choose to use different lookup strategy for each target entity. In this list you will be able to see the following options.
    • Lookup method - there will be 4 options available (This option was introduced in v7.1, it used to be a different setup in previous releases - without the Alternate Key option)
      • Primary Field - The lookup will be performed based on the target entity's primary field. When you choose this option, any value in "Target Text Field" will be cleared.
      • Manually Specify - You can choose whichever text field to be used for lookup purpose. Note that this option is not available for partylist fields, as the only possible way to do Text Lookup for partylist field is the primary field.
      • Alternate Key(since v7.1) - You can choose to perform lookup using CRM Alternate Key for the specific entity. This option provides the capabilities to look up on one or two fields as defined by the Alternate Key selected. In the case that the Alternate Key is defined by two CRM fields in the lookup entity, the input value passed to the lookup field will be used for the first field of Alternate Key setup, and you will need to specify an input for the secondary key field, as shown below. Note that Alternate Key is a feature introduced in CRM 2015 Update 1, which is not available to a previous CRM version.
        Text Lookup Screenshot
      • <Opt Out>(since v5.0) - When chosen, the component will not perform text lookup for this particular target entity. In this case, a GUID input (or an empty value) will be provided for the concerned lookup entity. This option is particularly useful for the migration of partylist fields. If that is the case, you may want to do Text Lookup for systemuser entity, but not the other entities such as account, contact, lead, in which case, you will be providing the GUID input for those lookup entities.
    • Target text/integer field - This column allows you to specify which text/integer field will be used for the lookup purpose from the lookup entity. In the case the lookup method is chosen as Alternate Key, this is where you choose the Alternate Key that's defined in CRM.
    • Exclude inactive - When chosen, the component will exclude any inactive records from being used for the lookup purpose.
    • Optional default value (if no match) (since v5.2) - When specified, the component will use this default value to perform the lookup should the input value lookup fail. This can be useful in some special scenario, for instance, if you try to migrate the account entity with ownerid field being set up to use text lookup feature, and you however don't plan to migrate all systemuser records to the new CRM system (either those users have left the organization or they are no longer using CRM system). For those migrated users, the text lookup works fine. For those users that were not migrated, the text lookup feature will fail, in which case you can set a default value here (the user's fullname) so the component will default to the user specified when the lookup of the primary input value has failed.
      Note that when the input value for the lookup field is empty (or NULL), text lookup will not be performed. Therefore, the optional default value will not be used in case that the input value is empty.
      Note
      that the optional default value can be "NULL" (case-insensitive with quotes removed), in which case it will perform a lookup using the input value, then the string literal "NULL". If that still fails to find a match, the component will set the lookup field's value to the empty one (NULL).
      Note that since v8.0 release, the optional default value supports using SSIS variables. When doing so, the variable should be in the format such as @[User::VariableName] or @[System::VariableName].

In addition to the above options, Text Lookup feature also offers the following three advanced options since our v5.0 release.

  • Ignore case (since v5.0) - When chosen, the Text Lookup will perform a case-insensitive lookup. For instance, "ABC Company" will be treated the same as "abc company".
  • Report error on duplicates (since v5.0) - When chosen, the Text Lookup feature will report an error when a duplicate is encountered at the time the lookup cache is populated.
  • Skip record if lookup fails (since v7.4) - When enabled, the Text Lookup feature will skip the row when the lookup fails. Note that when this option is enabled, the skipped rows will not be sent to either the Default Output or the Error Output of the destination component.
  • Cache Strategy (since v5.0) - You can choose from one of the two options:
    1. Full Cache - When chosen, the component will populate a full cache of all records from the lookup entity before starting to write to target CRM system. This is the preferred option when the number of records in lookup entity is small. This option is the default mode when v4.1 or an earlier version is used.
    2. Partial Cache - When chosen, the component will gradually build up lookup cache as the data load progresses. This is the preferred option when the number of records in lookup entity is significantly large. For instance, if you have more than a few hundreds of thousands of records in lookup entity, and you are only processing a few hundreds of records for your primary entity, Partial Cache mode would provide better performance.

Working with principleobjectaccess Entity

Since v2.0, we added support of writing data to principalobjectaccess (POA) entity. To write to principalobjectaccess entity, you can use the following three actions.

  • Create, which will be a GrantAccess message that shares the CRM record with the intended team or system user
  • Update, which will be a ModifyAccess message that modifies the sharing of the concerned CRM record
  • Delete, which will be a RevokeAccess message that un-shares the CRM record with the intended team or system user

CRM Destination Editor

When writing data to POA entity, you need to provide the following values:

  • accessrightsmask - Access Rights Mask can be an integer value added up by any combination of the following numbers.
    Read = 1
    Write = 2
    Append = 4
    AppendTo = 16
    Create = 32
    Delete = 65536
    Share = 262144
    Assign = 524288
    accessrightsmask is not needed for Delete (RevokeAccess) action, therefore the field is not available for Delete action.
  • objectid - The CRM record's ID that you want to share or un-share.
  • objecttypecode - The CRM record's typecode. If SOAP2011 endpoint is used, you can use entity's name.
  • principleid - ID of the systemuser or team that you would like to share or unshare the CRM record with.
  • principletypecode - Typecode of above the principleid. It should be either 8 (systemuser) or 9 (team). If SOAP2011 endpoint is used, you can use entity's name, which would be either systemuser or team. 

Working with accessteammember Entity (since v4.1)

Since v4.1, we added support of CRM Access Team feature, which was introduced in CRM 2013. To provide this capability, we designed a virtual CRM entity called accessteammember, which allows the following two actions in CRM destination component.

  • Create, add a user to a CRM record's access team
  • Delete, delete a user from a CRM record's access team

After you have selected accessteammember entity, you would need to provide an input for the following 4 fields.

  • recordid: the CRM record's ID (in GUID) that you try to add (or remove) user to (or from) its access team
  • recordidtype: the record's entity name
  • systemuserid: the CRM user you are trying to add (or remove) to (or from) the access team
  • teamtemplateid: the access team template's primary key

NOTE: accessteammember is not a real CRM entity, it is not supported by CRM 2011 or earlier.

Error Handling page

The Error Handling page allows you to specify how errors should be handled when they happen. 

CRM Destination Editor

There are three options available that you can choose for the component's error handling. 

  1. Fail on error
  2. Redirect rows to error output
  3. Ignore error

When Redirect rows to error output option is selected, the error handling behavior might be different depending on the version of our software you are using.

  • If you are using v5.0 or a later version, it will only redirect the rows that have failed to the error output (the successful ones will be directed to the Default Output of the destination component which is a new output in v5.0).
  • If you are using v4.1 or an earlier version, it will redirect all rows to the error output including those that have succeeded and those that have failed. In case you need to further process CRM records after the destination component (such as logging CRM records to a different system, or writing to a different CRM entity using a subset of available fields) when using v4.1 or an earlier version, you must choose the "Redirect rows to error output" as the Error Handling option. Then attach a Conditional Split component to the CRM destination component. In the Conditional Split component, evaluate the ErrorCode column (an output field added by the CRM destination component) and check to see whether it has actually erred out. The Conditional Split should typically have two output branches, one is ErrorCode == -1, which is the success path, and the other one is ErrorCode != -1, which is the failure path indicating that an error has occurred when writing to the CRM.

In the error output, you can see the following columns:

  • ID (version 4.1 or earlier) - Contains the newly created CRM record's ID, which you can use to write to log or further process using additional data flow components. Note that this column has been moved to the Default Output of the destination component in v5.0 which has a new name called CrmRecordId.
  • ErrorCode - Contains the error code that is reported by CRM server or the component itself
  • ErrorColumn - Contains the name of the column that is causing the error. Note that this column is not always populated
  • CrmErrorMessage - Contains the error message that is reported by CRM server or the component itself

NOTE:  Use extra caution when selecting the Ignore error option, since the component will remain silent for any errors that have occurred. 

In the Error Handling page, there is also an option (since v5.2) that can be used to enable or disable the following output fields for the destination component.

  • CrmRecordId - Contains the newly created CRM record's ID, which you can use to write to log or further process using additional data flow components.
  • IsNew - Contains value to indicate whether it is a newly created CRM record, or an existing one. This is useful when you use Upsert action.

NOTE: If you don't plan to use any of those fields for any further processing, it is generally recommended to turn them off, so you don't get any warning from SSIS by complaining that those fields are never used, and it should also provide a slightly better performance by doing so. Note again this feature is only available since v5.2.

In addition to the above settings, the Error Handling page also offers the following an Additional Outputs option since our v8.0 release.

The "Skipped Rows" output can be useful when the Text Lookup is set up to Skip Records if Lookup Fails or the destination component’s Handling of Multiple Matches option is set to Ignore or the error-handling mechanism is chosen as Ignore error” in the Error Handling page.

@[System::CreatorName]