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>We are aware of intermittent issues in accessing the learning content</p>

We are aware of intermittent issues in accessing the learning content

Personalize your learning.

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?

Please try again later

Sorry, we encountered an error

Try again or reset results to continue browsing

We didn’t find what you’re looking for

To continue, please log in

Your session has timed out

Validate your skills and learning by completing the certification exam and gain a highly recognised accreditation.

Book your certification exam

Complete the assessment to validate your SAP PartnerEdge competency qualifications.

Ready to take your assessment?

Learn about the key features and essentials in the latest release to help you prepare for the Stay Certified assessment.

Prepare for assessment

Learn new skills you need at your own pace with our bite-sized lessons.

Prepare for certification

In your My Learning account you can view your certification and learn how to take your Stay Certified assessment.

Ready to take your Stay Certified assessment?

Explore {title} at SAP Learning. Find out more!

Assessment

Course Completion

Knowledge Badge

Certification Exam

Theoretical Exam

Schedule

External Course

Practical Exercise

Practical Test

External Hands-On

External Resource

Learning Journey

Learning Journey Assessment

Lesson

Live Session

Practice System

Quiz

Scenario Based Assessment

Course Assessment

Course

Stay Certified

Subscription

System Based Assessment

Test Out

Unit

Video

Video Playlist

Week

<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.