However, the restriction can be overcome through strategic permission configuration. The process involves five steps:
Establish a new permission set titled “Integration Permission Set” with no assigned license.
Set up a dedicated user with the “Salesforce Integration” license and assign the “Salesforce API Only System Integration” profile.
This represents the critical phase. The Salesforce API license defaults to severe restrictions. Navigate to “Permission Set License Assignments” and enable the “Salesforce API Integration” license—this restores standard functionality.
Access the Integration Permission Set’s App Permissions section and activate the “Run Flows” checkbox.
Complete the configuration by assigning your newly created permission set to the integration user through the Manage Assignments button.
Note: Without enabling the permission set license in Step 3, attempting to assign the permission set generates an error message regarding incompatible user licenses.
]]>There are two key identifier types: the Alias identifier (a random GUID assigned at contact creation) and the xDB.Tracker (assigned only during web visits). The problem occurs when merging contacts—the system fails to preserve the xDB.Tracker, leaving contacts unable to process subsequent web visits.
When affected, users encounter an error stating “Contact…must have a tracker identifier.” This breaks tracking functionality until users clear their cookies, forcing them to essentially restart their session.
The solution involves creating a custom pipeline processor that executes before Sitecore’s standard conversion process. This processor checks for missing xDB.Tracker identifiers and regenerates them via xConnect API calls when necessary. This fix resolves approximately 60 daily errors down to roughly one occurrence every 4-5 days.
This approach is a temporary workaround—hopefully the community can help reproduce the underlying issue for official Sitecore resolution.
]]>The system generates a message stating “ERROR General error when submitting contact. Exception: Sitecore.XConnect.Operations.FacetOperationException Message: Operation #0, AlreadyExists,
Similar FacetOperationException errors appear, indicating batch execution problems with contact classification operations.
A patch exists in the Sitecore Knowledge Base addressing this contact-saving issue.
Even with the patch installed, errors continue in specific configurations:
When clients switch between servers or devices, in-process sessions disconnect, severing the contact reference. New sessions attempting to save contacts generate duplicate operation errors.
Move both shared and private session state to Redis, SQL Server, or MongoDB using Sitecore’s official configuration walkthroughs.
Note: SQL implementations won’t function in Azure SQL due to temp database requirements.
]]>The contact tab houses all xConnect-related contact data, including:
Identifiers - A comprehensive list of assigned identifiers and merged accounts, containing source, identifier value, type, and validity status.
IsKnown - Indicates whether a contact has been identified using methods beyond Sitecore’s default identifiers, such as through the IdentifyAs() function or direct xConnect assignment.
ExpandOptions - Displays available facets for xConnect interaction, functioning as a registry of known facets.
ConcurrencyToken - A GUID that Sitecore applies to all facets. Mismatched tokens during save operations trigger an error, preventing facet overwrites. Each object possesses a unique token.
LastModified - Timestamp of the most recent contact modification.
Id - The primary contact identifier visible in Experience Profile URLs and the Contacts table within shard databases (distinct from tracker contact IDs).
Current interaction information specific to the active web visit:
Comprehensive listing of all pages visited during the current interaction, excluding pages from previous sessions. Contains page title, URL, and blank-window status.
Records goals triggered during web visits or out-of-channel activities, displaying engagement value, title, UTC timestamp, current/past visit designation, and associated event data.
CurrentGoals - Goals triggered within the current session, enabling Sitecore to personalize based on present-session activity.
PastGoals - Goals triggered before the current visit, allowing personalization based on historical behavior. Current session goals transition to past goals upon visit closure.
Lists all available contact facets populated from ExpandOptions. Example Personal facet contains birthdate, name components, gender, job title, language preference, concurrency token, and modification timestamp.
Tracks current and historical pattern card assignments based on profile scoring:
CurrentProfiles - Active pattern cards with profile name, score, count, and pattern details.
PastProfiles - Historical pattern cards with scoring frequency, totals, and individual score records by key-value pairs.
]]>The tool displays:
The project originated in 2017 when James Williamson requested a way to identify a user’s profile during an active session without terminating it. The initial solution used a simple API endpoint (/apis/v1/visitordetails) that returned xConnect profile data in JSON format.
The upgrade transforms this functionality into a user-friendly interface accessible without browser extensions. Instead of viewing raw JSON strings, data now organizes into distinct tabs for clarity. The tool supports both desktop and mobile viewing, recognizing that personalization experiences differ across devices.
The team plans to expand beyond read-only capabilities, adding functions such as triggering goals, enrolling users in pattern cards, merging contacts, and executing other operational tasks.
The release targets Sitecore 9.x versions and is available on GitHub at the Bonfire repository.
]]>The implementation involves three main steps:
Install the EPExpressTab NuGet package to begin development.
Build a model to hold your facets and other necessary data. Then construct a view model extending the EpExpressViewModel class, which specifies the CSHTML view location for the EP tab.
Create the presentation layer injecting into the new EP tab. I incorporated Sitecore’s styling to maintain visual consistency with Speak.
EP Express Tab automatically detects classes inheriting EpExpressViewModel and generates corresponding tabs in the core database. The tab naming derives from the TabLabel property, and the rendering automatically integrates into Experience Profile’s presentation details.
For multiple tabs, developers simply create additional view models and views. The tab ordering can be adjusted within the core database at /sitecore/client/Applications/ExperienceProfile/Contact/PageSettings/Tabs/.
I needed to find a contact ID using a known email address. In the previous version, a simple Mongo query would retrieve this information. However, in 9.x, the identifiers are encoded in hexadecimal format.
Using an online hex-to-ASCII converter, I confirmed these are standard hex characters without encryption. Here are two SQL queries to work with this data:
This query displays all email address identifiers in readable format using a CONVERT function to decode the hexadecimal values.
SELECT CONVERT(VARCHAR(100), Identifier) as Email
FROM [xdb_collection].[ContactIdentifiers]
WHERE Source = 'email'
This query finds a specific email address by converting the search term to VARBINARY format and comparing it against the stored Identifier column.
SELECT *
FROM [xdb_collection].[ContactIdentifiers]
WHERE Identifier = CONVERT(VARBINARY(100), 'user@example.com')
This approach allows direct database access to retrieve contact information from the xConnect shard databases.
]]>In Sitecore 8.2 Update 6 and 7, as well as 9.1 Update 1, the kernel contains a bug that crashes when encountering bad internal links. This malfunction can either crash the Rebuild Link Database application or bring down an entire site. When Sitecore attempts to resolve a link without proper error handling, it can fail deep within kernel code, producing a “System.FormatException: Unrecognized Guid format” error.
The solution involves a Sitecore knowledge base patch that completely replaces the Sitecore.Kernel dll. However, this presents a patching challenge: Sitecore does not publish hotfixes through NuGet packages; they release fixes through their knowledge base for selective implementation.
I advocate for the first option, emphasizing intentional CI builds that eliminate snowflake servers—environments with undocumented, manual patches.
Create an Infrastructure.Patch project within Helix solutions to manage all patches centrally. This approach ensures consistency across environments and simplifies upgrades. By incorporating patches directly into build processes, organizations can achieve their goal of rebuilding production environments entirely through CI scripting.
]]>I originally created a JSON application for version 8.2 and have maintained it through the 9.1 release cycle.
The system retrieves requested facets through ContactExpandOptions. My approach involves accessing the xConnect server configuration to obtain all KnownModels (available facet models), passing these into ContactExpandOptions to retrieve and serialize all facets.
The resulting JSON output includes:
Check the GitHub releases page for access to the tool.
]]>.Reset() extension method to clear facets, but this functionality was removed in 9.x.
When attempting to replace an existing facet with a new instance, developers encounter the error “Facet already exists on the contact.” This occurs because xConnect tracks facets using a ConcurrencyToken to maintain data integrity and prevent unauthorized overwrites.
Rather than manually resetting each property to its default value, I created a custom extension method. The extension creates a fresh facet instance while preserving the original ConcurrencyToken through reflection:
public static T GetFacetWithDefaultValues<T>(this T facet) where T : Facet, new()
{
var newFacet = new T();
var concurrencyTokenProperty = typeof(Facet).GetProperty("ConcurrencyToken");
var originalToken = concurrencyTokenProperty.GetValue(facet);
concurrencyTokenProperty.SetValue(newFacet, originalToken);
return newFacet;
}
This approach copies the concurrency token from the existing facet to a newly instantiated facet, allowing xConnect to accept the replacement without triggering integrity validation errors.
The solution also includes functionality for cases where developers want to swap in a pre-populated facet while maintaining the concurrency token.
]]>