Martin Sanderson: Is Case Data import something Siteglide may not offer down the road?

I hope the developers will choose to add. Here's why...

I have clients that collect a lot of critical information using the web forms. Information that informs sales, email content, landing pages, and used to segment email lists. But this information is not captured in the contact info section of BC. It's only captured in the CASE section.

It seems like data too important not to migrate. Not something to discard.

Well, that's my thoughts, anyways. Would be curious to know if others think the same? Thanks Martin.

Helen Eichel: It's not something we've decided not to do, no. It's just there's a lot of moving parts on this one that need to be considered and planned fully before we can implement it.

For example, CSV exporting from BC can give you a list of cases, those cases define a Case ID and a CRM User ID, to link them both together in the database. However, there does not appear to be anything specific linking the case to a form in this export, so where import the data to?

Now, assuming we just say "let us import this list of cases to any form", what if the form fields are different or have been revised and improved upon as part of a migration? Where would the data then be held?

Perhaps we say that adding a page to CRM for "cases" similar to how BC had it would then allow the system to display any cases generated by forms AND cases just generally imported, that are not attached to a form, but are linked to a CRM User ID.

This also brings with it, other things that must be considered. For example, what if we have this page in place and you import some case data, but make a mistake. Do you now manually have to do through and select thousands of cases to delete them? I'd suggest that we'd need some way to filter the case data based on date of import, or existing form that it's attributed with.

Hopefully that gives an idea of the complexity of this request - we're open to thought on how you'd like it to behave!

Martin Sanderson: Thanks for your response.

Here are my thoughts on the CASE data, and how I see it ....

Most of the CASE (form) data that is critical is coming from B2B customers indicating what product(s) they are interested in, what industry are they in, their function, where they found us, If they're interested in becoming a brand ambassador, etc. This is really critical information for their business, to retain. And the information can be associated with an email and name.

Ideally, I'd like to have a separate tab for BC CASE stuff, just to keep it easier to manage. And I'd prefer that the Custom Field Set for the standard contact CRM data be kept to one tab.

Otherwise, I plan on having one tab, where I'll separate out the custom field sets: a) BC Contact CRM, b) BC Email Stuff (which would retain optins, etc, should we ever need to demonstrate optin standing), and c) BC Case CRM. And within the Custom Field Set Tab, each Custom Field Set will have it's own subhead to keep it a separate section.

I don't imagine that many (or any) contacts will have all the possible Custom Field Set fields filled. Although it's possible that for some contacts, tab pages may run deep.

BENEFITS:

1) All the data fields will be accessible for creating forms in Siteglide, so data collection will be consistent between BC and Siteglide.

2) Data will be retained

CONCERNS:

1) Yes, big potential for import errors. Would appreciate all the help you're willing to provide! My thought was to import CASE data by form name, but to have all form fields, for all forms, be included in the Custom Field Set. So for each import, I would be updating data for existing contacts.

Thoughts? Know you and your team are working super hard. So thanks very much.