Required Access and Permissions

For us to access your data, we will need a User account for each system involved in the integration, and each User account will need privileges or permissions on the data we will access.  During the development and testing process, we ask that you provide Administrator level access for these Users.  This will greatly help with access, setup, and troubleshooting.  We understand that best practice is to use service accounts with fewer permissions, and we encourage changing to such privileges after development is complete and your integration is launched.


If providing Administrator access during development is not possible, there may be delays during the development process beyond our control.  However, if and when necessary, we will provide all relevant information to assist with creation of custom privileges needed for the integration to run successfully.  Keep in mind as you work with your Solution Architect and Developer, that any changes you make to scope/design or any optional features you include in your integration such as Ownership Sync, may require you to increase the privileges for our User accounts.


For example, if your integration is set up to only read Salesforce Contact data and copy it into HubSpot Contacts, we would need "read" privileges on Salesforce Contacts, and "write" privileges on HubSpot Contacts.  However, when we sync data from one system to another, we often write record IDs back to source records, so that we can continue updating the same target records instead of creating duplicates.  In general, providing us "write" access to all records involved in the sync is sufficient to ensure a continued and uninterrupted integration.  If you need to further restrict access, we will work with you to understand exactly what minimal privileges will be required based on your needs.



Business Process and Design

An integration should be as efficient and simple as possible.  Its main purpose is to provide a universal data experience to all of your users, no matter what system they work in.  To achieve this goal with speed, accuracy and reliability, and because our integration represents a third-party, background, invisible process to you as the client, it is important that business process is not written into the design.  Best practice for an integration is for it to move data from one location to another with minimal effort and minimal transformation.


For instance, it makes perfect sense to copy critical Lead information across systems when it is updated in one system and meets your requirements.  However, it would not be best practice to have us Close or Qualify the Lead as part of this process.  This kind of business logic should be handled at the source and/or target systems by your own ratified automation and workflows.  Not only does this reduce the workload on your integration, but it also allows you to maintain control of these processes without needing to contact our support team or wait for results.



Sync Direction and Risks

As we sync your data, it will "flow" in a given direction.  HubSpot Company data may update or create data in NetSuite Companies, and in this case would say it travels in the HubSpot => NetSuite direction.  There are many possible directions for data to move in your integration, and we will work with you to define them carefully.


If data will sync in both directions for any given type of record, it is called bidirectional.  An example of this might be syncing Contact data between HubSpot and Dynamics CRM.  Different fields/properties may be mapped for each direction, and you can think of them as two separate processes.  One Contact from each system may update the same or different fields in the other, but one process will happen before the other.  The order in which these processes will run is important in determining which system of yours is treated as the System Of Record (SoR).


Bidirectional sync carries additional concerns, which can get quite in-depth.  Two of the larger risks when working with bidirectional sync are data looping or homogenization.  Here is a blog post and a technical KB article on our portal that comment on some of these risks, as they pertain both to simple or more complicated integrations:



Integration Speed and Sync Schedules

When you work with our Solution Architect, you will be able to stipulate the conditions where we will consider a record "eligible" to sync.  For instance, you may only want Leads with a Status of "Open" to sync to another system.  We can accommodate almost any request such as this, but note that adding more complex logic may cause the integration process to run more slowly.  For instance, if we need to examine pre-existing data in the target system and do a comparison, this will mean an extra query will need to be made to the target system, which adds extra time to each and every record being processed for sync.  In the case of large numbers of records being synced, this added delay may become significant.  In general, the more simple your integration, the faster it will run.


Our integrations run using a minimally-invasive communication method known as Web Services.  These are passive services from your systems (HubSpot, Salesforce, etc) which respond to our requests for data.  These services respond at their own metered rate, in order to avoid slowing down their users' experiences.  This means that our integrations will only operate as quickly as your systems can serve them data, and you should expect them in some cases to take longer than such a process might take at a User's desk.  In other cases, it may be considerably faster, since we operate programmatically and do not require a user interface to be rendered.


Web Services let us avoid writing plugins or other apps which would need to be embedded into your systems.  This keeps security approval light and avoids the need to write, maintain and access custom code on disparate platforms.


Because of how Web Services work, all parts of our Integrations run on revolving schedules, often every 5 minutes.  Each time they run, they will query your systems for data that meets the requirements you set forth for sync, and will attempt to determine and sync only what has recently changed.  We constantly strive to optimize our processes based on your needs, so in most cases of light usage you will see data begin to sync within 5 minutes.  However, this is only a guideline, and in the case of making bulk changes where hundreds or thousands of records may need to be processed, there will be some delay before the job "catches up".



Field Mappings and Conditional Field Sync

When you work with us to "map" a field for sync, you are telling us which field from a given type of source record in your source system will map into which field and record type in your target system.  For instance, you may want to map a Lead's "Phone" field from Dynamics CRM into a Contact's "Phone" field in HubSpot.  In general we can accommodate any request, but there may be some cases where translation is required or you as the client will need to make changes to one system or another to ensure that they properly mirror each other.  For a CRM Optionset field to map correctly into a HubSpot Dropdown property, they must have options that all match up.


In some cases you may want certain fields to sync only under certain conditions.  You may want a CRM Lead to only update a HubSpot Contact's "Phone" property if that property is already empty.  In these cases we would need to do an additional query on your HubSpot data (as described above) and to compare that information.  However, even when we do this, we must still write to any field/property that is mapped.  So if we compare data in this way and decide that the existing data should remain as it is, we are in fact writing the same value to this property again.  If a field/property is mapped and the record syncs, that field will always be written.  This is not behavior we can alter, because it would require running separate web service requests for each field, which would slow the integration down so much as to be infeasible.  In many cases this does not pose a problem, but in some cases for some systems, the act of writing to fields may trigger automation or other cascade effects, so you should bear this in mind during the design discussions.