WDCi Blogs

Thanks to everyone who visited our stand at Cloudforce in Melbourne and Sydney.  With over 600 in Melbourne and more than 1000 in Sydney, we definitely enjoyed ourselves. Thanks to Boomi and PingIdentity for sponsoring the booth with us.  We had a great time having the Ping guys on our booth in Sydney.

Here’s a few shots from the events:

People crowding to get to our booth

Walter at our booth:

Donal with Andrew Hindle from PingIdentity at our booth:

Want to see how easily you can integrate Salesforce and Netsuite?

Grab a pina colada and some popcorn and check out our short demo showing a common use case - Integrating Opportunity and related objects between Salesforce and Netsuite.

We have recently completed a large Netsuite migration project. This migration exercise involved ~1,000,000 records. Some details on this engagement can be found here.

One of the most important factors for a successful data migration is ensuring the data is as clean as possible before inserting into the target system. Inserting the data into the target and cleaning later involves a lot of extra work.

Before migrating your Netsuite data, consider a clean-up of the following objects as they typically generate a lot of duplicate data:

Account Addresses

When you export the Customer records to CSV, you may get duplicate records due to the addresses and contacts. For example, if you have a customer with 4 addresses and 3 contacts, you will likely end up with 12 records in total.

Export your Account data first and see if you can merge or remove duplicate records before migrating this data.

Opportunity and Opportunity Product

This is also similar to the behavior above. If you have one opportunity with 5 opportunity line items. When you are exporting the opportunity to CSV, you may get 6 records in total. Each opportunity line item will appear as a record inside the CSV file.  This may not be valid to merge or remove, but it’s advisable to check the Opportunity records to determine if you can clean this up before a migration.

If your Netsuite environment contains a substantial number of Accounts, Contacts and Opportunities, it’s worthwhile to merge and clean the data prior to importing into the target system.

Our migration planning guide may be of help if you are planning a data migration exercise.

Stop by our booth and say hello http://www.salesforce.com/au/cloudforce/.

Maybe you are thinking, what’s so hard, I just dump the data out of system 1 and insert it into system 2, maybe, maybe not.

How long will it take to migrate your data from one or more systems to another system?

It really depends on a few factors:

1. How easy it is to export data from the source system(s)?
2. How easily data can be imported into the destination system(s)?
3. The volume of  data.
4. The number of objects and fields involved.
5. Do you need to transform the data before importing into the new system?  and if so, how complex is the transformation?
6. Are their data dependencies, ie object 1 must be created before uploading object 2?
7. Do you need a data cleansing exercise to remove/fix bad data and merge duplicates?
8. If you need to clean the data, should it be loaded into an intermediary data store to make that process easier.

The quality of your data is a really important factor in how long the whole process will take.

If you have such a requirement, check out our migration planning guide or feel free to contact us.

Ever thought of how you can achieve the following:

• Login to Salesforce with your LDAP or Active Directory credentials?
• share the same login credentials with all your SaaS applications?
• have the flexibility to provision/de-provision users ?

With Ping Identity, all this is possible. You can configure your LDAP or Active Directory as the identity store and your users can authenticate using their credentials in your company directory.

Besides Salesforce, PingIdentity’s PingConnect and PingFederate can authenticate to more than 60 SaaS applications.  Anything that’s SAML capable will work with PingConnect.  If the app isn’t SAML capable, no problem, just use PingFederate.

Another interesting feature that makes Ping Identity the unique player in the market is the user provisioning feature.  You can easily activate or deactivate a user in just a few clicks.

Contact us to find out how we can make your life easier!

Lets say that you have a database internally that holds some of your key data. You have just implemented a CRM in Salesforce and you want to be able to reference (lookup) this data in real time.

You have a couple of choices:
1) Copy all the data into Salesforce and keep the two systems synchronised. This is ok, and if you need the data frequently may be the best way to go

2) Keep the data in the database, and just look it up from there.

For option 2, this used to involve a fair bit of setup and a bit of custom coding to get it to all work nicely, and more importantly to work securely. A couple of recent features to two products has just made this easier.

Firstly, Salesforce.com has introduced a new feature to allow you to generate your own certificate to securely call a web Service inside your company firewall and be sure that the originator of the request was in fact your own Salesforce instance. See the following write-up for more info.. http://wiki.developerforce.com/index.php/Making_Authenticated_Web_Service_Callouts_Using_Two-Way_SSL

Secondly, Boomi has released a feature to expose a database query, or Stored procedure as a web Service that can be called in real time. This release from Boomi has opened up a whole range of possibilities to quickly and securely expose internal services to SaaS based applications.

For more information on this or other integration stories give us a call at WDCi..

Well, it depends…

Ok, I realise that isn’t helpful, so here’s an example.

First some assumptions/caveats on Salesforce and Netsuite integration:

1. Your implementations of Salesforce and Netsuite are in reasonable order, customization is ok, we’re just assuming that you haven’t used duplicate field names in Netsuite and if so, that you understand your data and can identify these.
2. We also assume that you will play a large part in the identifying the fields to be mapped in each system.
3. Systems will be locked down during development.
4. Data migration is not part of the exercise.
5. We’re using an integration tool that has connectors/adapters for each system.

So, assuming the above, here’s an idea of how long we would take to integrate 3 common objects between Netsuite & Salesforce, ie Account-Customer, Contact-Contact and Opportunity-Opportunity or Opportunity-Invoice.  Our approach is rapid not reckless:

Can we do it quicker?

• It depends on the assumptions above and how quickly you can work with us to complete the job.

What typically impacts the time-line?

• Field mapping detail and complexity
• A clearly defined and well understood business process
• System availability, People availability (sign-off, testing)
• Data cleanliness (see this blog on the impact of data quality)

Want to know more, just ping us and we can quickly give you a scope of how long it would take.  You can also check out our We Did section on our website for some examples of recent integrations we have built.

Let me share with you about what I have learned in Parature Integration.

Parature offers a great feature that allows you to define field dependency. You can control the visibility of the options based on the controlling custom field.

For example, Operating System is the controlling custom field and Operating System Type is the depending custom field:

• If you choose Windows, you can only see XP and Vista
• If you choose Linux, you can only see Redhat and Ubuntu

This is the document returned from Parature API.

Interpretation:

• Custom field 21 is depending on custom field 20
• If option 1 (Windows) is selected, enable custom field 21 and its options (10 & 11)
• If option 2 (Linux) is selected, enable custom field 21 and its options (12 & 13)

If you want to integrate Parature with other systems, all this dependencies may give you headache. You may try this parameter enforceRequiredFields=false to bypass this constraint.

When we kickoff our integration projects we run through a checklist with the client.

If they have been running the systems for a period of time, we always review the quality of the data, we call it a Data Quality Assessment (someone in marketing came up with that, not me, ok).

Usually the client asks:

Why do I need a Data Quality Assessment?

Consider this:

1. Have you been using the systems involved for some time?
2. Have you tried to keep them in sync manually? For example: Create Company ABC in both Salesforce and RightNow manually.

If you have, then our advice is to assess the quality of the data before investing in integrating the systems. If the data isn’t cleaned now, we’ll increase the problem once the systems are integrated and bad data is being synchronized.

What’s involved in a Data Quality Assessment?

This involves profiling your data to review if the data is ‘clean‘ , ie do you have excessive duplication and can we merge records to clean this quickly.

What if I don’t clean the data?

Consider the following example:

1) The process for Account/Contact creation in Salesforce is a manual process done using the information in Right Now:

Click to view full picture

2) Given the manual data entry it’s possible for the following to exist:

Click to view full picture

3) When we integrate we will end up with RightNow Case and Opportunity data linked to the wrong Salesforce Accounts.

This is what would occur after running the integration process on the above data:

Click to view full picture

Looks messy right? Definitely something for you to think about before connecting the systems. IMO some type spent up-front will save a lot of pain and $ in the long-term.

It would be like eating health food for a week.