PX user identification when launching PX engagement from JO

We're revising our PX implementation due to ongoing identifier issues, but I can just help you with a bit of your problem as I went down that rabbit hole some time ago*:

To link a Person record in CS to a User in PX:
· CS field: Company Person [PX User Id]
· PX field: aptrinsicId. You can find it in the OOTB User export, I couldn’t find it in the UI last time I checked.

Company/Account Identifier Mapping
· CS field: Company [PX Account ID]
· PX field: accountId.  You can find it in the OOTB Account export

If you need to correct or update existing IDs in the CS side, you can utilize rules engine. I've successfully done this by using the OOTB Account and User exports from PX via S3.

Historically, the data load relied on rules engine, so it could be possible that this setup is custom, but the Company and Company Person fields I mentioned are Standard Fields. I don't know if an OOTB connector existed then, so I can't speak to its current usage or functionality but I guess that you can check your current mapping in the connector's settings?

One more thing that I forgot.
Just in case, by the OOTB exports I meant these found under Integrations → AWS S3 Settings:
 

Hi ​@romihache 

Found some time to dig into the Company and Relationship Person objects

• On Relationship Person, I have:
  • Standard field PX Trendminer PX Production Aptrinsic Id
  • Custom field PX User ID (which we are populating via Rules)
• On Company Person, I have nothing related to PX, neither on Person

The latter is not really a problem, as we map everything on Relationship level. The Standard field on Relationship Person, which I now assume is being used for the mapping, doesn’t look very useful though, as it is empty for the large majority (but not all) of recently created contacts (while our custom field is not).

Can’t figure out why some users do get associated either…

Our PX-CS integration contains some custom in-between objects, which likely explains why it’s not working out-of-the-box, but then why would it work in some cases???

Any idea if this could be a use case for unification?

Yes, this could definitely be a good use case for Unification.

Right now, you have PX identifiers coming from different places (the PX connector, your custom Rules field, and the older standard field on Relationship Person). Since Journey Orchestrator only checks the standard PX User Id field during PX Engagement steps, any gaps or inconsistencies there cause the mixed results you’re seeing.

Unification can help by providing a single, consistent PX identifier across all contacts. It allows you to:

• bring together the different PX ID sources you currently have,

• decide which one should be the authoritative PX User ID, and

• ensure that the standard PX User Id field in CS is populated correctly for every Person/Relationship Person.

This would remove the inconsistency and make JO → PX engagement triggering more reliable going forward.

We don’t use Relationships and I don’t have hands-on experience with the Unification feature either, but for what I’m reading you can setup up a preference order for data source, but that would only help with part of the problem (if you have it) such as duplicated records. But again, this is mentioned at the Company/Person levels so I don’t know how it works for Relationships.

I feel for you because took me a long time to detangle what was happening with our instance, and the “why this one works and this other doesn’t” required a deep dive in both PX and CS (Analyzer + Data Management) to catch which process was doing what. It was a complete reverse engineering effort, relying on created/modified at datetimes and specific records to “find the Minotaur”