How do we safeguard the Eloqua contacts that one business segment is using from a separate business segment?
Configure Contact Security!
Many organizations have a broad range of contact data, and they need to control what employees have access to that information. You can use contact security in Eloqua to achieve this. Contact security allows you to create labels, and apply them to users and contacts in your database. Users in a security group can only access contacts that are assigned the same label(s) as them. Any combination of labels can be assigned to a contact or a group, and this provides a significant degree of control over your contact data. This functionality is also known as Label-Based Access Control (LBAC).
For example, if you have geographically separate business units, then you can create labels based on geographical region in order to keep your targeted audiences separate. Once you have defined the users or groups that will require specific sections of contact data, applying the appropriate labels will prevent from those users or groups from accidentally mishandling other contacts outside their region.
Contact-security supports the management and combination of labels so that access to contact data is clearly and explicitly defined. Determining what labels are applied to which contacts depends on your current business processes, and the needs of your organization.
Labels and categories
Categories should accurately reflect the types of labels they contain. For instance, many companies categorize labels by region or country. If your organization has competing divisions, sales organizations, channels, or user responsibilities, then you may want to set up a category for that structure, and define labels for each division or channel.
Assigning labels: how it works
With an out-of-the-box Eloqua installation, contacts that are added to your database will not have any label; those contacts are searchable and visible by all users. Administrators can create labels from within the User Management area of Eloqua, and subsequently apply those labels to the appropriate user security groups.
Labels are then applied to contacts through a program that you build and activate in the label assignment workflow canvas. This canvas functions similarly to the standard program canvas, but is itself a separate area for the purposes of label-based access control. Contacts are pulled into the program by a data source step, are fed along a path and filtered through decision steps, and arrive at an action step where labels are applied (or removed, depending on your configuration).
A label-based program can be designed in a number of ways. For example, you can use the Listener step to listen for all new contacts as they are added to database in real time, and immediately add them to your program. Alternatively, you can create segments of existing contacts and send them through your program for the sake of organizing your database. All program steps are configured directly on the workflow canvas.
Learn more by watching the video! - How to Create a Label Assignment Program
Best Practice Tips:
- Keep it simple. We recommenced no more than 2 or 3 categories when starting out.
- Define criteria for the division of contacts in advance, and set business rules within your own sales divisions (if applicable).
- Optionally, you can create a basic label (and its category) and assign it to an administrator security group. Then, configure the assign default label settings so that all new contacts will be given this label by default. This will restrict access to all new contacts before they are processed by a label program.
- A campaign or program inherits the security labels of the person who (re)activates it. This means that if a user creates and activates a campaign consisting of contacts with "Security Label A" applied, and a second user with "Security Label B" deactivates and reactivates the same program, all of the contacts with "Security Label A" will be immediately removed from the program. This ensures that a user cannot directly process contacts for whom they have no security rights. If you need to run a campaign created by another user, use the Run As User function to avoid changing the security labels of that campaign.
Oracle Eloqua Help Center: Contact Security
Topliners Community: Contact Level Security: Talking Through the Use-Cases
Topliners Community: What is Eloqua Contact Level Security? 8 Steps for Success
Oracle University Academy Course: Eloqua 10: Database Security (Web Based Training)
Download this Guide: Eloqua Contact Security and FAQ
How do we provide separate reporting dashboards for the different business segments?
This could accomplished in Insights by creating custom dashboards that could be filtered. An Analyzer license is required for creating custom reports and dashboards in Insights. Learn More with the Academy Course: Eloqua 10: B2B: Insight for Reporters (OBI)
What Form notification changes will be needed for the different business segments?
Form processing steps for notifications can be configured with conditional steps to determine which notification to send depending on what was captured on the form, or a contact field that has been flagged with their Business Unit potentially. Learn more with the Oracle Eloqua Help Center: Processing Form Data
If one business segment has a blocked contact in the master exclude list, but the other business segment needs the contact, how to proceed?
Once Contact Security is configured and contacts are being labeled properly, they could be removed from the master exclude list as Contact Security will keep other business units from having the ability to email to that contact.
Should contacts with no security labels be accessible to all users?
By default contacts that do not have labels assigned are visible by all users. Depending on your business requirements this may or may not be acceptable. I suggest creating a filter that adds all of your recently created or modified contacts to your security program. However, this is not foolproof. If contacts are added that do not have values in the fields that determine security the program will be unable to assign security labels and those contacts will be visible by all. There is an easy fix. By creating an “Unknown” label in each category you can add steps to your program to assign the Unknown label if none of the criteria for applying labels is met, these unknown labels can then only be assigned to system administrators. You can also include a step to add them to a shared list for your system administrators to follow up on.
Can a single contact be shared by multiple divisions/business units/brands?
- If yes, is there a limit to the number of groups who can have access to a contact?
If a record cannot be shared then the first step in the CLS program is to remove all security labels so that they can be assigned based on the current field values. If they can be shared you would not want to clear the labels allowing multiple labels from the same category to be assigned. Depending on the nature of your business the number of assigned security groups could grow exponentially, you and your key stakeholders will need to determine if this is acceptable or not.
- If yes, does it matter that users from both security groups can see activity history?
For example, both Division A and Division B have access to email@example.com if Division A sends an email, and Bob clicks and submits a form the Division B user will also be able to see that activity. For many organizations this is a non-issue and for some it is desired but depending on your org structure it may be something to take into account.
- If no, can ownership of a contact record ever change over time?
Whether ownership can change over time will impact the way your CLS program is configured. If ownership cannot change you may only need to have net new contacts run through the security assignment program. If it can change then you will need to have every contact that is updated re-evaluated for security.
Which contact fields will be used to determine what security group(s) they belong to?
Depending on the source of your data, how it is coming into Eloqua and how it is formatted will determine how ownership of a record. Once the fields that will determine security are identified it is critical that they be included whenever data is being brought into Eloqua. For example, every file imported will need to include the fields that determine security. Likewise, each form that is created will need to have the related fields (whether hidden or input by the contact) so that security can be assigned.
Do you need to restrict user views based on security groups?
Some contact fields may only apply to specific security groups. If this is the case you will want to be sure to create Contact Views for each of your security groups.
Will you need to report on contacts based on security groups?
This use case likely won’t apply to many organizations but can be challenging for those who fit this scenario. If marketing operations, or system administrators are launching campaigns that include contacts spanning multiple security groups and there is a need to report response rates at the security group level reporting gets tricky. When a user runs an Insight report the report will show total results. However, if that user drills into the reports they will only see the contacts that they have permission to access. In order to report on just the contacts related to the security group you will need to create custom reports.