>> Continuation from Eloqua vs Marketing Cloud – Introduction.
Due to the major differences in core architecture, both platforms have significantly different data and security models.
The following sections elaborate more on this, and what should you be aware of before making purchase decisions, or migrating from your existing platform.
Table of Contents:
- Flat org vs Business Units
- Single app vs. Studios and Builders
- Security Groups vs. Roles and Permissions
- Security Settings
- Sandboxes
- Summary
Flat org vs. Business Units
This section covers the overall architecture in terms of data, assets, and functionality.
Oracle Eloqua
Eloqua, as in technical terms referred to as “Eloqua Instance”, represents a single business unit setup, where all records reside within the same data tables of that instance.
This means that all records are available to all users within the same instance. The same applies to any other asset, campaign, program, etc.
This by default represents quite a challenge, especially if your organization is a large enterprise with multi-regional-specific data model requirements.
In the next part of this article, we elaborate more on the data model. But in simple terms, in Eloqua, there is only one Contact table, linked to an Account, or Custom Object.
There are dozens of challenges with this setup, but luckily Eloqua provides two solutions to tackle this issue.
- Contact-level Security, also known as Label-Based Access Control (LBAC)
- Upgrade to Eloqua Enterprise
As part of the first solution, Eloqua allows labeling of the contact records based on, say, country. So a contact from Denmark will have a label “DK”, Norway “NO”, etc. These labels are then assigned to specific users, so the mapping takes place. In that way, a user from Denmark can only see records from Denmark, etc.
In the second solution, you have to upgrade your Eloqua to Enterprise Cloud Service, which will give you 20 instances in total.
One important thing to notice is that data, assets, campaigns, or anything, in general, can’t be shared across these instances.
Additionally, Eloqua Enterprise Cloud Service is at the highest end offering by Oracle, meaning, it cost a lot!
You can find more info about the various editions and features here.
Salesforce Marketing Cloud
Marketing Cloud, on the other hand, does something completely different.
When you provision an account depending on the edition, it comes with a predefined Business Unit – BU.
This BU is your local instance where all your data, journeys, and automation are configured.
Typically you will create one BU per country, or Brand, e.g.
– Corporate
— Brand X
— Brand Y
In terms of multi-regional requirements, you can always provision another BU. And you can have many, actually up to 1000 BUs without affecting the platform performance. You can push to more if needed, but be aware, as this can potentially degrade the platform performance.
In general, this means that all your data and journeys, are specific to a single BU, and can be accessed by users assigned to that BU.
Unlike Eloqua, you can easily share data, journeys, and other assets across Business Units.
This flexibility, or scalability in general is one of the key features that makes Salesforce Marketing Cloud an enterprise-grade solution.
Single app vs. Studios and Builders
Now, this is another thing that makes these platforms very different in the approach of how functionality is bundled and how data is related.
Oracle Eloqua
From this perspective, Eloqua is quite simple, as it is represented by a single instance. All features are built within the same application, same database, and hosted within the same data center.
You can access these various functionalities through a simple top menu, as shown below.
Whether you create a campaign, a program, or a report, all these applications draw data from the same data table/s.
This makes it very simple to work with, and the learning curve is extremely fast!
Salesforce Marketing Cloud
Marketing Cloud on the other hand is a very, very different story!
Salesforce Marketing Cloud is represented as a bundle of Studios and Builders. These are basically products that you can provision based on your business needs and requirements. See this as you build your own customized marketing cloud.

These studios and builders are basically different platforms and tools acquired by Salesforce at some point in the past.
But this doesn’t have to mean anything bad or seen as a disadvantage. All these products are well integrated and seamlessly embedded in the Marketing Cloud GUI, as shown below.

Product Groups
Salesforce officially groups these products as such:
- Marketing Cloud Messaging and Automation: Email Studio, Mobile Studio, Journey Builder, and Interaction Studio.
These products help you create, build, deploy, and manage communication across different marketing channels at scale, which help map the ways you communicate with your customers. - Marketing Cloud Data and Advertising: Advertising Studio, Audience Studio, and Data Studio.
These products help you create custom audiences and combine data from any source to deliver more targeted marketing. - Marketing Cloud Social Media: Social Studio.
This product lets you listen to digital conversations; engage across marketing, sales, and service; and publish information for key discussions your customers are having about your brand. - Marketing Cloud Measurement and Analytics: Datorama and Google Analytics 360.
These products help you understand what’s working—or what’s not—across all your marketing efforts, using cross-platform reporting and insights
Another important thing to mention which significantly affects the overall architecture is the way these products are integrated.
Unlike Eloqua, where everything is in the same application, Marketing Cloud approaches this a bit differently.
Since most of these products have been acquired by Salesforce at different times, in order to build the Marketing Cloud, they belong to different Tech-stacks.
This means, that each of them has different unique record keys, which have to be mapped across in order to relate the data.
This can make the overall architecture quite more complex, not only to configure but also to maintain.
However, put that aside, this flexibility, to plug-and-play different studios and builders is one of the extra key traits making Salesforce Marketing Cloud an enterprise-grade solution.
Taking Eloqua as a reference point to compare with Marketing Cloud, in terms of Salesforce products that would be: Email Studio, Journey Builder, Web Studio, Analytics Builder, Content Builder, and Contact Builder.
Security Groups vs. Roles and Permissions
So far, we can see the differences in the underlying architecture for both platforms and therefore expected complexity in terms of data and access security.
Oracle Eloqua
Starting with Eloqua, the overall platform access is controlled by Security Groups.
These are configured in a single place within the instance and offer quite granulated control of privileges over features, and data.
A Security Group is a bundle of permissions, and multiple groups can be assigned to a single Eloqua User.
In this way, you can design the right security access model based on your requirements.
The screenshot below shows an example of one security group and assigned Interface Access permissions.
Salesforce Marketing Cloud
Due to the integrated studios and builders, configuring the right security in Marketing Cloud can be quite a task.
Overall, Marketing Cloud takes advantage of Roles to control privileges and access with plain Create, Update, View, and Delete permission.
Depending on the feature access, there can be additional permissions, such as Assign, Administer, Associate, etc.
These Role Permissions are configured on a BU level.
Some of the additional products within the Marketing Cloud might require additional security configuration. For example, Social Studio requires a setup of User and Workspace Roles, etc.
Multiple Roles can be assigned to a single Marketing Cloud User.
Security Settings
Oracle Eloqua
In terms of Security Settings, both platforms offer a lot.
Starting with Eloqua, the following screenshot shows all security settings that can be applied to the instance.

As you can see it is quite an extensive suite of features, however, MFA is not one of those.
You can though configure a Single Sign-On – SSO, which can have MFA, and in that way address the problem.
For most enterprise organizations, this shouldn’t be an issue, as by default they configure SSO, typically with Microsoft federation.
However, if you can’t do that, this definitely represents a GDPR challenge.
Salesforce Marketing Cloud
Marketing Cloud offers similar possibilities. As part of the Security Settings you can configure:
- General Security, e.g. password policy, etc.
- Multi-factor Authentication
- Login IP Allowlist
- Export Email Allowlist
- Domain Allowlist
- Domain SSL Certificates
As you can see MFA is part of the settings, and typically works by Email, SMS, or the Salesforce Authenticator App.
The following screenshot shows the general security settings.

Sandboxes
This is another key feature that helps in the process of evaluating if one platform is enterprise-grade.
All large organizations design and build features based on a multi-tier quality assurance model, typically spread across many gates.
So for a platform such as Eloqua or Marketing Cloud, it is critical to have the necessary capabilities to enable Sandbox environments.
Likely they both offer this possibility, however with slight differences.
Oracle Eloqua
You can provision a Sandbox in Eloqua, which by default will be linked to your original instance. Once this feature is enabled, you can sync the Sandbox.
This is typically a manual process and what it does, is simply a complete mirror copy of the production instance, excluding the data.
It is extremely important to mention that this process is always one way, production -> sandbox.
That being said, any configurations implemented in Sandbox will have to be manually implemented in the Production instance.
This creates quite an overhead in production time, so make sure when you plan to double up on hours.
Salesforce Marketing Cloud
In Marketing Cloud, a sandbox would be an additional Business Unit. Depending on the architecture complexity typically you can branch both Prod and Sandbox BU on the same “sibling “level, or nested.
Unfortunately, there is no way by default to keep these BUs in sync. That would be a manual effort or done by a third-party solution.
Luckily salesforce offers a way around this challenge, which might ease the pain, at least a bit. With the Marketing Cloud Package Manager, you can migrate configurations from one BU to another.
You can read more about the Package Manager here.
Summary
Okay, I hope this was not too detailed, but I think it is important for you to know the differences and pros and cons in general.
Form a high-level platform architecture, and depending on your organization size, contact base, and needs, perhaps Eloqua will do the job well.
However, if you want to utilize the true enterprise-grade architecture and scalability, perhaps Marketing Cloud would be the way to go.
This is especially the case if you need to communicate across channels. As we will mention in the later sections, Marketing Cloud works well with Mobile Push, SMS, and Social. Eloqua is a bit behind on that front.
In terms of security, both platforms are quite strong, with a slight advantage for Marketing Cloud, especially around the MFA setup.
The overall sandbox limitations in both cases can become a critical issue, so make sure you really assess what works best for your org.
That was it for this topic, more to come soon!
About Advension?
We are a Salesforce Certified Partner and a Digital Experience (DX) Consultancy House, located in Copenhagen – Denmark, with over a decade of extensive experience in architecting and developing Marketing Automation and CRM platforms and technologies.
Want to know more? hello@advension.com