Name: Discovering the CIAM for B2B Data Model in SAP Customer Data Cloud
Uploaded: 2024-8-12
Duration: 293 s
Description: This video explains the CIAM for B2B data model. Through detailed explanations and practical examples, the video elucidates how this data model facilitates seamless interactions, enhances security protocols, and drives efficiency in handling complex identity requirements.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><div><div><div><div><div>This video explains the CIAM for B2B data model. Through detailed explanations and practical examples, the video elucidates how this data model facilitates seamless interactions, enhances security protocols, and drives efficiency in handling complex identity requirements. </div><div><br></div><div></div></div><div></div></div></div></div></div></div></div></div></div>

Discovering the CIAM for B2B Data Model in SAP Customer Data Cloud

So we're going to talk a little bit about the data model that's associated with the B2B solution. Now the B2B solution builds on top of the existing B2C data schema or data models. So I suggest you get familiar with that first before diving in the B2B model,  Largely speaking, there's a few different entities here. We have the concept of an organization which is obviously new in the B2B context. We have the concept of an organization member, which is new in the sense that there's a relationship with the organization, but not new in the concept that it's a contact in a database that uses an application. So on the left hand side we have the organization entity. And there are a number of predefined fields that are associated to the organization. First, we have an org ID. This is an internal identifier that we use to pass into authorization requests which can't be changed. This is the primary key. We have a, a BP ID or a business partner ID. Now this is intended to be the ID from an external system. So this might be the ID from your S/4HANA system or your CRM system. We have an organization name, organization address fields, organization status, which can be active or disabled. And then we can define custom fields on that organization. So we could say that it's a particular type of organization or we could say it's located in a particular region. We can define whatever custom fields we want to for that organization. And the really important thing about that is that we can actually use those custom fields in our policies to drive access. So moving to the right hand side, we look at the organization member. And if you're familiar with the data model in Customer Data Cloud, you'll see the UID, the profile object, the data object, preferences and subscriptions, which are all part of the standard account structure in Customer Data Cloud. What you'll notice perhaps that you might not have seen before is this group's object. And this is where we store the relationship between the organization member and the organization. And that is then represented by this middle piece, the relationship. So obviously, a member can be associated to more than one organization. And we would have one of these relationship structures for each of those organizations within that group's object. So it's part of the relationship. We store a few different things. We have the org ID, which is the org ID, on the left-hand side. This is just relating that organization to the member. We have a list of roles that are associated to that user, and that organization. Obviously, someone can have different roles as part of different organizations, and therefore they need to be associated to the relationship itself. Now the important thing to note here is that for most of the roles you just see an ID. So you'll see it just like a random 32 character UID with the exception of the delegated admin role, which is listed in free text. And the reason it's done like that is so that people don't just look at the account structure and say, okay, someone has this role of technician and therefore we should grant them access to something because then we're completely bypassing the policy-based access control. We also have the business partner ID in here. So this is the same business partner ID, which is a foreign key on the left-hand side. We store information about department and job title, which of course can change between organization members' relationships to different organizations. And finally, we have a status somewhat, whether someone is active or disabled as part of that organization, which could be controlled from the delegated admin console. These fields cannot be customized. So these are static fields within that relationship. Just to visualize that a bit more, we can see on the right-hand side, json objects, which represents that group structure that I talked about. So under groups we have a sub object group organizations which stores an array of organizations. So it could be one or more. In this example, we have one organization and then we can see the different fields that I've talked about before. So the point I touched on about the roles where you can see the delegated admin role in plain text, but for all other roles, you'll see a UID. And then we see the business partner ID, department, job title, the internal org ID, and then the status.