Looking for people using Data Exchange Framework or Dynamics CRM Connect

Hi everyone,

Sitecore Product Manager for Data Exchange Framework here. Some changes are coming to DEF. These changes also affect Dynamics CRM Connect.

We want to make the update process as easy as possible. In order to do that, we need to know how you're using the product.

If you have some time to share with me your experience with the product, I would love to talk with you.

10 Replies

  • Hi Adam,

    I have started using the DEF as a Proof of Concept. Please see below my inputs:

    1. Does not support creation of Branch Template.
    2. A little complicated to create the mapping.
    3. Lots of configurations.

    What would be great is to have a proper documentation about how to configure the DEF for the different purpose. Note that I was using it to import from CSV.

    Thanks
  • Hi Adam:

    I'm attempting to use the DEF to integrate our custom CRM with Sitecore. I've managed to push data into Sitecore at the contact level, and I'm now looking into pushing data into a custom facet which will house subscription and product purchase data. Specifically, I need this to be dynamic for subscription records as they are added and removed. I haven't found any examples of using the xDB Contact Facet Collection Property Value Accessor, but it appears to be what I need and that's where I'm focusing my attention right now. I've used the Dynamics CRM Connect as a reference for some of my research.

    Walter Enzor
    Elliott Wave International
  • In reply to Hishaam Namooya:

    Hi Hishaam,

    1. Branch templates

    Can you describe how you would use branch templates with DEF? For example:

    • Would you want to map values to different items in the branch?
    • How would you expect to handle cases where a mapping applies to different items on a branch, but the branch has already been created?

    2. Mapping complexity

    Yes, mappings are a little complicated currently. We plan to build a UI that lets you configure the sync process and the mapping visually. We think this will significantly increase usability. I expect the UI will start with mapping and then move onto the sync process.

    3. Lots of configurations

    A lot of the configuration that must be handled manually can be automated. An example is the sample tenant that comes with Dynamics CRM Connect. It comes with several pre-configured sync processes. The idea is that you can configure the mappings that you need, but that the sync process - where most of the complex configuration exists - is provided for you.

    The UI I mentioned in #2 will also help with this. Many aspects of the configuration are easier to understand when presented visually. An example are the relationships between pipelines. So in addition to being able to guide you through the process of configuring things, it will be able to present options within a context where those options make more sense.

    But if I may justify the configuration: our goal with the product was to build something that could handle a lot of different requirements while minimizing the amount of code that is needed.

    You see the result of this. The complexity is moved from code (where it cannot be changed without a developer) to configuration (where it can be changed without changes to code, but is much more complicated because the options that are otherwise hidden in code are exposed for everyone to see).

    If you have any ideas on how we can make this tool easier for you to use, please let me know!

  • In reply to Walter Enzor:

    Hi Walter,

    You're definitely on the right path here. Dynamics CRM Connect offers examples of 2 different approaches you can use. (Btw, if it were me, I'd consider option 2 first. I think it will be easier to build, test and manage.)

    Option 1

    If we were on Reddit I would have given you gold for mentioning the xDB Contact Facet Collection Property Value Accessor. It shows you're reading the documentation!

    We use this component in order to write the CRM contact's email address to xDB.

    The advantage of using this approach to model the data you want to store is that the model is available out of the box via types defined in Sitecore.Analytics.Model.Framework (such as IElementDictionary). This is the API that the xDB Contact Facet Collection Property Value Accessor was designed to work with.

    It also allows you to do things like storing separate values which can be identified. For example, you may have work and home email addresses, so it needs to be as easy as possible to find the precise email address you need at any given time. 

    The disadvantage to this approach is that it adds a lot of complexity to your configuration. One example is that you need separate mappings for the key (such as "work" and "home") and the value (the specific email addresses).

    Option 2

    Another option is demonstrated by how we store marketing list membership. Each contact in may be a member of 0-to-many marketing lists. In Sitecore we save the IDs of the CRM marketing list on a custom contact facet.

    In xDB we store the value as a single string (comma-separated). This makes it much easier for us to update the value in Sitecore. 

    This approach does present some challenges. For example, you need to completely overwrite existing values on the xDB contact. So the first step of the sync process clears out the current value on the contact, and a later step writes the current values back to the contact. This can result in unnecessary updates in xDB, but we decided the reduced complexity was worth it.

  • In reply to Adam Conn:

    Thanks for the reply. I'm glad I'm heading the right way! The limitation of Option 1 is exactly what I ran into so I have been looking into how to implement something like Option 2. I saw the step in the Dynamics marketing list process to clear out the current value and then insert the new values. This would be a necessary evil for us as well since a customer can add or remove subscriptions at any time. We also don't want to specify a key for each item since we have over 45 potential subscription codes and hundreds of products that could be purchased. I began testing with addresses and realized that facet was set to require an identifer, so I'm building out a custom facet to house our data much like the marketing lists are configured and will be working on the integration once that is in place. Thanks again!
  • You should get in touch with one of my collegues Morten Engel - me@alpha-solutions.dk - he is using it extensively

    Br
    Klaus
  • Hi Adam. I would definitely like to go over what I am trying to accomplish with it. It is somewhat unique.
  • In reply to Adam Conn:

    Adam:

    I don't have an instance of Dynamics CRM running to look at the marketing list structure, but if I understand you correctly, you don't use named properties in your collection of marketing list memberships.  If we would like to use an element structure similar to the facet defined in this article, is there any way to insert elements with multiple properties with the current value accessors?  In my example, we would have an element collection of Subscriptions defined under a custom facet, with each subscription element having multiple properties but no identifier like the Addresses collection.  Two property examples would be SubID and SubCode.

    I just want to make sure I'm not overlooking something simple.  Thanks.

  • In reply to Walter Enzor:

    Hi Walter,

    I'd say there are 3 options.

    OPTION 1. Create a custom value accessor

    This is basically hard-coding the value accessor to know how to deal with a specific facet value. I don't recommend this approach, but there are cases when it's appropriate.

    Advantages: fast

    Disadvantages: custom code, maintenance

    Best for: prototyping/testing/learning, or unusually complex values, or when you don't have time to do it "the right way".

    OPTION 2. Use the built-in components to configure a compound value accessor

    This is a completely configuration-based option. In the future this will be a more viable option (when we have a configuration UI).

    Advantages: doesn't require custom code

    Disadvantages: configuration can be very complex, requires strong understanding of framework components 

    Best for: simple-to-mildly complex values

    OPTION 3. Hybrid value accessor

    This is the approach we use for the more complex value readers and writers (like the ones used to interact with contact facets). We try to avoid creating new readers/writers. The base ones tend to support most of what is needed - if you know what they are and how to use them. 

    If you look at the provider for Dynamics CRM, you can see examples of this in the value accessors used to interact with CRM entities.

    Advantages: good balance of complexity and usability

    Disadvantages: requires small amount of custom code for converters, requires strong understanding of framework components

    Best for: mildly-to-highly complex values

  • Yes I am using it and am interested in talking with you about it. I plus 3 other folks on my team can provide much feedback on 1.3 version; also, looking forward to 1.4 version.

    David (MVP)