For one of our customers, we had to come up with a massive strategy. The request was to have 12 to 16 European countries within on single Eloqua environment. An important point of this request was to have each country only have access to their own contacts. Our goal was to create a blueprint that abled us to roll out to new countries without having to do double work.



Our Challenge

The challenge during this implementation was:

  • The coordination in the Netherlands, and technical support from India and the US
  • To create a uniform data model and Eloqua structure
  • An efficient and stable way of connection between countries and Eloqua environment
  • Old Marketing Automation systems are being faced out
  • All countries would need to receive correct user training
  • Having a tight deadline per country, which meant sticking to deadlines was key


How did we come so far?

During the early start of the project, a pilot phase was set up for the first country rollout. During this phase, we created a blueprint for easy rollout to new countries. In this blog post I will explain the three main points we worked on:

  • An initial data model
  • Worked out a middleware setup
  • Created a draft label workflow.


Because of the limited number of available fields, the shared data model was our top priority. We worked out a strategy of standard fields, as well as local fields for each country. By copying all default fields into an Excel sheet, we were able to create the base model. Each country would receive this version and a combining presentation. This explained the different field options as well as the limitations for our data model. Having this data model enabled us to explain its potential during the next phase.


The next step during the pilot phase was around creating a stable middleware layer. This layer gives us the possibility to connect to (almost) unlimited back-end systems. But we had to make sure data was being fed from the local county into Eloqua without any error. This meant develop field by field, and test each field. One of the issues we ran into, was contacts without email address that were being loaded. After several discussions with the business, it was clear we had to come up with a solution for this. The solution for this was to change our contact identifier from email to a new unique field. We decided to switch to a combination of contact id, ISO country code, and a source system identifier. This meant we had to alter the shared data model to be able to handle this change. This was one of many we made on the data model throughout the first few months of the project.


One of the requests from the client was to have strict boundaries on contact security level. For this, we worked out a workflow that would tag contacts when loaded into Eloqua. Each contact would have two labels, one country tag and one 'all' tag. With the 'all' tag, we were able to give admins more rights to search for contacts. Each contact enters the workflow at the moment of creation. All possible current labels or email groups are removed. The next step is to link the contact to a county. A required field is present within the data model that shows the originating country. A small screenshot of our label management workflow with several countries present already is shown below.


A screenshot of the final label

By only building this label assignment workflow, we were not there yet. We also created several security groups that covered contact security on user level. So, for each tag, a security group was set up with only business unit settings. All other settings removed to keep security groups clean and organised. Each country would get his own local security group that manages their contacts.


After the security of contacts, we also worked on a structure to secure assets between users. We wanted to make sure, users from one country could not edit or remove assets by accident. To reach this stage, we removed asset security from the standard user roles. This means that the standard roles only give access to the systems and screens but not to assets. For each, country separate asset security roles had been set up. This makes it possible to give users access to edit assets only from their own country. Below a simple overview of the different user groups we set up.


1. Access Management

          a. Admin

          b. Local admin

          c. Marketing User

          d. Sales user

2. Asset Management

          a. Country 1

               i. Basic

               ii. Advanced

               iii. Reader

          b. Country 2

               i. Basic

               ii. Advanced

               iii. Reader

3. Contact management

          a. Country 1

          b. Country 2


With the blueprint that we fixed during this pilot phase, we made it possible to roll out Eloqua at a faster pace. Where the first country went live after four months, the next few countries needed three. We documented everything during the pilot, new countries received documentation to prepare the country kick-off. This makes it possible for us to have several one-hour workshops instead of two-day sessions on specific topics. Countries were able to do different activities without long and extensive sessions. And I strongly believe that we made it possible to roll-out to a next country in only two months.


The list below consists of points that were important to us during this implementation.

  1. Integration between different back-end systems and Eloqua
  2. Security settings to manage assets and access apart from each other
  3. Contact labeling workflow to do contact security
  4. Calculate enough time between different countries.
  5. Make use of sandboxes to test integration work
  6. Uniformity and standardizing work as much as possible


Lessons Learned

One of the major issues we faced was that we kept tweaking the data model over and over. Although it gave the first countries the option to improve the data model, this also meant rework and simultaneous sometimes re-uploading thousands of contacts. It also created a lot of work for our middleware team, as well as the test team. Instead of changing the model, we should have focused on improving the roll-out. This could make it possible to do several country roll-outs at the same time.


Another issue we came across was the unawareness of several countries. To have focused discussions, we cut the project in small groups with kick-off sessions at the start of each group. During the roll-outs, we still noticed a lot of unfamiliarity with the product and its options. They were not aware of what they could do with Eloqua as well as what they could expect during the country roll-out. Countries also felt that Eloqua was being pushed to them without consultation.



During this project, we worked together with two other implementation partners. One of them focused on the business side, while the other worked on the implementation. As a team, together with the business, we were able to create a stable blueprint that is able to roll-out to different new countries in a short period.


The customer has now a stable and leading Marketing Automation up and running. Several different countries are doing better lead management, and send more SQL's back to the countries. Compared to previous Marketing Automation programs (like Unica and Hubspot) that they had running, users spend less time on administration work and more on time on improving the customer experience.


With the support of our Customer Success Manager, we have discussed plans for the future. One of them being around moving CDO's to a different database outside of Eloqua. Using the Feeder Service within the AppCloud Developer Framework, we would be able to make use of more decision data (order history of yearly returning products and other kinds of orders). Because different countries are uploading large quantities of CDO data, we are pushing the limits of CDO usage. Although this is currently put back on the backlog, it is still something we are keeping a close eye on.


With the created blueprint, we have made a strategy for the customer to roll-out new Eloqua environments throughout the rest of the World. All the steps are created in such a way that it is standard and uniform, not related to a single country. And with the uniform method of using Eloqua throughout the business worldwide, it makes it easier for Global Marketing to organize and structure marketing activities. And for Global IT, it is easier to keep track of all their activities around Marketing Automation, as it is a uniform process.


Setting up one Eloqua instance for several countries creates a lot of difficulties. And this takes a considerably longer time to put in place than other (simpler) implementations. With a solid discovery phase at the beginning of a project, and establishing a blueprint (and sticking to it!), it is fairly doable to set up and run one Eloqua environment for many countries.


Based on my experiences, I had also written a post about how to work with REST-API’s and Postman. The post explains how to start using Postman and the Eloqua 1.0 and 2.0 REST-API'S.


University courses used during this implementation

B2B: Data Cleansing

B2B: System Integration

Eloqua 10: User Management

Eloqua 10: Database Security

B2B: Database Configuration