Ryan Cox – Architecture Patterns & DevOps with Agentforce and Data Cloud

Share with

Description

This session will walk through detailed architecture patterns for developing solutions with Agentforce and Data Cloud, including examples from some of the largest Salesforce customers, how Data Cloud One and other Salesforce clouds fit into a multi-org Salesforce architecture, and what development environments and devops look like around these solutions.

Ryan Cox – Distinguished Technical Architect, Salesforce. Ryan Cox is a Distinguished Technical Architect at Salesforce, currently focused on Salesforce’s Agentforce and Data Cloud platforms. He’s helped some of the largest tech companies architect solutions around the Salesforce ecosystem. He lives near a small mountain town called Nederland, Colorado where he’s an avid snowboarder and backcountry skier.

Learn more:

Transcript

Okay. Hey, everybody.

I'm gonna get started because I have an hour and a lot of things to talk about.

So, welcome to architecture patterns in DevOps with Agent Force and Data Cloud.

No small topics here.

But I'll get through it.

My name is Ryan Cox. I'm a technical architect at Salesforce. I've been at Salesforce for seven years, pre sales technical architect. I've been covering mostly very large high-tech accounts at Salesforce for most of the times that I've been at Salesforce.

Amazon, Google, a lot of people in Dell, Cisco, IBM, things like this. So, pretty large accounts and, most of everything that I'm gonna talk about today that I'm gonna show you has come out of customer projects that I've worked with for them.

I also thank Gearset for letting me be here.

Maybe some of you have been to some of my past presentations. I've actually been at every one of the DevOps streaming so far and over the years presented or had sessions, about a variety of things.

Last year, this time last year, I actually did a very similar presentation. It was the first iteration of this data cloud DevOps presentation. Over the last year, a lot of things have changed. So, if you happen to have been there last year, there are a lot of new things to talk about especially with the invention of Agent Force, sitting on top of Data Cloud.

So I'll get into that later.

So, So, forward looking statements, I know you've seen this before but this is actually I do have a few things in here that are roadmap items that are future.

So, I'll point those out, along the way.

And so, this is what I'm gonna cover today.

So, Agent Force and Data Cloud architecture. So, how they fit together, things to think about, like the ways that Data Cloud actually enables Agent Force to do a lot of things in places where it's actually required.

Org strategy in Data Cloud One. So, very important to actually start thinking about how you organize your Salesforce orgs, to, to make it work with multiple orgs feeding off of the same data cloud tenant, considerations around that. I'll get into that. And then finally, DevOps. So, how do you actually do DevOps for both Agent Force and Data Cloud together from lower environments to other environments, right?

So I'll start with this. I know everybody's seen this but just to make a couple of points around the overall strategy that Salesforce is going forward with and has been for the last year is Data Cloud is very much a central piece of the product strategy for the overall Salesforce platform.

It's right in the middle for a reason.

Literally, all of our Salesforce products across the board including things like Marketing Cloud, Tableau and so forth are actually gonna start using Data Cloud as the primary data tier for those products going forward.

Maybe you've heard of Tableau Next that was announced at TDX that is very much based on top of Data Cloud.

Perhaps you've heard of Marketing Cloud for growth or advance. This is a new version of Marketing Cloud that literally sits on top of Salesforce and requires Data Cloud for segmentation and the processing that you're doing for those segments.

And then of course, Data Cloud feeds agent force across the platform and I'll show how that works and some detail around what that means, right?

So, everybody's probably heard of Data Cloud. You use Data Cloud.

Yeah.

You know, the primary purpose of it, right, is to bring data in from either, you know, all of your existing orgs or some of them, right? So, you can bring data together from multiple orgs, from external sources.

We now have a lot of real time capabilities of data cloud and APIs and SDKs for bringing data in from literally everywhere.

MuleSoft has a connector for ingesting data into data cloud if we don't have a connector for it.

And the purpose of it is to drive, you know, bring all this data together to drive your use cases across all of your different Salesforce apps, right? Sales, service, marketing, all that kind of stuff. And then more recently to actually drive more accurate responses from agents that might be relaying on data from outside of Salesforce or from across your Salesforce ecosystem, right?

You also probably have heard this. Mark talks about it a lot on his public announcements and such.

The metadata framework is kind of all the same.

Partially true.

But the metadata that lives inside of Data Cloud is literally living also inside of your Salesforce org and then you can take advantage of anything that you brought in from outside into Data Cloud just as if it's a native object inside of your Salesforce org. That's kind of what that means. Now, the metadata framework part of it, I'll get to what that means in terms of deployments from lower environments to production environments or other environments for the DevOps process.

It is different, with Data Cloud and there's also a set of dependencies that you have to kind of take into consideration when you're building agents that are reliant on Data Cloud data.

Right? So, I'll get into that.

So, to get started, I'm gonna introduce some of the nomenclature around Data Cloud if you're not familiar with it, and common patterns, architecture patterns. So, you know, this is actually how I think about data cloud, how I present it to customers all the time and build architectures for what they need to do for how Data Cloud fits into your enterprise architecture, right? So, one of the very first patterns that a lot of people use especially if you have multiple Salesforce orgs which a lot of customers do, A lot of even small customers will have two orgs for various reasons, right? Maybe a sales org and one that's dedicated to customer support service, that kind of thing.

So, you know, first thing, top left is your Data Cloud instance is actually always tied to a Salesforce org and we call that the Data Cloud home org. So, that is the management plane for Data Cloud. So, every everything you're doing for configuring Data Cloud is done by an admin that lives inside of that home org.

And then, with multi org environments, you can bring in data from any Salesforce org and a very easy use case to implement on Data Cloud is to bring data from multiple orgs together inside of Data Cloud and then surface that into your Salesforce org for like if you have a common pattern also is a customer will have a primary sales org where all their sellers live. On the account page, they wanna see cases from a different org, for example. Very easy use case to do inside a data cloud for bringing in data. Right? So, some other nomenclature around here is that, what you're doing is bringing data in from data sets from any place, get landed into what you configure a data stream, the actual schema of that data lands in what's called a data lake object and when the data is getting ingested, it's living inside of this data lake object.

And then you do a mapping or data transform into what are called data model objects and those are your common data model inside of data cloud. That ends up being your kind of enterprise data model and data cloud for activating the data to all the places you need to. Another big capability of data cloud, is called identity resolution.

So, in this picture, if you're bringing in accounts and contacts from multiple cell source words, you probably are gonna have duplicates. This identity resolution is doing a matching process of matching those accounts together, those contacts together where you can come to this unified profile.

Probably you've heard of that, right? So that's the whole concept of data cloud for bringing together your data to make a common three sixty view of your customer, right?

Now, another thing that you can do, another kind of product feature that has gone live over the last year, this actually went live in October last year, is this concept of Data Cloud One. So, what this means is that all the things that you were doing in the Salesforce homework before for Data Cloud, in terms of being able to surface data from Data Cloud directly into flows, Apex could do SQL queries against Data Cloud data model, that kind of thing. You can do related lists from Data Cloud model objects, data model objects into your org.

Data Cloud One allows any other Salesforce org in your environment to become what's called a companion org and then this companion org has all the same capabilities as the home org at that point in terms of being able to retrieve the data and surface the data in Data Cloud as if it's native objects inside of Salesforce.

What companion orgs don't do is that you can't do any administration inside of Data Cloud. They just have read only access to the data.

But this is a very quick way to bring data together from multiple Salesforce orgs and surface it in any other Salesforce org. Common pattern for this would be also for mergers and acquisitions. A lot of companies will require other companies that already have a Salesforce org. If you already had Data Cloud in the picture, you can very quickly wire up the data, start ingesting the data from the objects since from that other org and then it immediately falls into your common data model inside a data cloud that you then can service backup to any source source org.

Right. So, going forward here in this picture, you've also got, so, you know, apart from just the multi org environment for Salesforce, we have like two hundred connectors now plus for bringing data in, in batch mode, in streaming mode with these APIs.

I'll talk about that more in a minute but we have like web SDKs so you can listen for behavior on your websites that gets pumped directly into data cloud in real time.

For mobile apps, this web SDK is supported inside of Experience Cloud. If you're running a portal of some sort on top of Salesforce, we have a native integration where you can just do the web SDK for real time behavior coming in and engagement coming in from your websites, from your Experience Cloud sites.

Another very important piece of connector that we have is what's called Zero Copy.

So, you probably have heard of that. We have this called Zero Copy Network where we're quickly expanding all the kind of the larger data sources that we can support for like the name represents. You can actually just point to the tables inside of that data source and the data actually just gets represented as a schema, as a data lake object and then you can do the mapping to your canonical data model and data model objects inside of data cloud and then those objects are actually virtual. So, anytime you do a query against the data model objects to bring the data into Salesforce, to do identity resolution, that kind of thing. The data is actually just being queried directly from that zero copy data source. So, right now the sources that we support for zero copy connector are Snowflake, Redshift, BigQuery and Databricks.

There are a bunch of other ones on the roadmap, for anybody that's using Trino, for Workday, IBM, WatsonX, data, these kind of things. Microsoft Fabric is actually gonna be the next one.

Okay. And then, what you're doing then is so any of the data that you brought in or pointed at, via zero copy, can be utilized across the breadth of the capabilities inside of Data Cloud. So, that includes identity resolution, the concept of calculated insights that might be doing joins across your data model to calculate values, segmentation and activation for marketing. So, you can build marketing segments off of your unified profile but filtered off of data maybe coming from Snowflake, for example. Or any of the behavior that you ingested from the real time web SDK coming in from your websites.

And then all of these objects and capabilities inside of data cloud can be activated and used back inside of any of the Salesforce orgs via this data Cloud One configuration.

For marketing activation to a growing number of marketing tools and ad services like our marketing cloud, of course, but we support a host of other ones.

Marketing segments can be published to B2C commerce also.

And then Tableau, I mentioned that earlier. So, Tableau Next actually is the semantic layer that we have sitting on top of Data Cloud where you can build a semantic layer on top of your data model inside of Data Cloud. And then Tableau connects directly to it for doing your dashboards based off of that semantic layer or any data model object inside of your data model inside of Data Cloud.

We also have the zero copy that I mentioned for Snowflake and Redshift and so forth.

We provide bidirectional. So, any of the objects, most of the objects inside of Data Cloud can then also be shared as virtual tables inside of those systems.

And that's a direct link. It's a live connection. So, if you're inside of Snowflake and you're querying that table, it's actually just doing a live query against your data cloud data model.

All right.

All right. So, we also have, yeah. So, we have this real time layer now. This is actually a fairly new feat set of features that has gone live over the last year.

So, this is actually, so, that unified profile that you're coming to inside of data cloud, we have this concept of data graphs. So, data graphs is kind of like a, if you think about like a tree structure, you might be familiar with querying data graphs in this tree structure, right?

So this data graph is things like, okay, all my unified profiles and like the last thirty days of cases that came from across my orgs or the last thirty days of engagement behavior from our marketing tool, from the website, things like that.

So, what we have now is this web SDK, the mobile SDK, also the ingesting API that we have for bringing data in from programmatically from any source, is part of this real time layer now. So, what this means is that within, and we, Salesforce defines real time in this case as we don't really publish SLAs but we kind of consider real time being five hundred milliseconds or less.

So, within one second of somebody doing something on your website, that engagement behavior like what page they looked at, what product they looked like to add on your website, is fed into this real time data graph associated with their unified profile so that you know other things about them.

And then also we have this new flow type inside of the cell source word called the automation flow, also referred to as the high scale flow. So this actually is a high scale flow that allows you to do, it's like, we support like fifty thousand flow invocations per minute, right? So, all the activity that you're capturing off of your website, for example, coming in from this real time web SDK gets input into the real time data graph and then you can fire actions off of that back inside of your cell source org, right? And do a lot of interesting things with it. So, one of the other things is it can feed into the real time segmentation for doing marketing segmentation.

This automation flow can do things like publish to Slack, can kick off an email journey or a marketing journey inside a marketing cloud via an API from that flow, automation flow.

And then, it can also, this real time data graph can also become part of what your agent is actually tapping into to drive more accurate behavior and answers to your users that are asking questions.

So, in agent forest service agents for example, you're, you know, they're asking questions around a particular case or whatever. You can see in that real time data graph what they just looked at on your website or anything, any other behavior that you might have ingested from an external system inside of Data Cloud that is part of that real time data graph. We also have a new feature, relatively new feature called Salesforce Personalization. It was called Einstein Personalization up until recently.

This is still a very new product over the last year.

This allows you to have these, kind of points where personalization points on your website that will feed in, will retrieve the real time data graph to dictate what like advertisement you put, what next best action you have on the website. So this is how everything kinda fits together from a data cloud perspective for real time behavior that you can do across agent force, across personalization, that kind of thing.

And then we also have, if anybody attended the last session with Shobi, he was talking about Einstein Studio and bring your own LOM, bring your own models, this kind of thing.

We have a feature in Data Cloud called Einstein Studio that allows you to do a couple of things. You can build predictive models off of your data inside of Data Cloud.

You can point to an existing model, a predictive model that you may have built inside of, SageMaker, inside of Google Vertex AI, inside of Databricks.

So you're pointing at an endpoint for a predictive model. You're registering that as an inference that you can call inside of Einstein Studio, a component of Data Cloud.

And then you can run those inferences or those predictive models to generate data that just becomes part of your data model inside of Data Cloud that you can use for servicing back inside of your Data Cloud One, Salesforce orgs, inside of you can use those to filter for marketing segmentation, kind of anything that I just mentioned that you can use. Now, other places you can also use that, use those predictive models are directly from Flow inside of Salesforce. So, any of your Salesforce orgs that are connected in this data Cloud One configuration can take advantage of the predictive models that you've registered inside of Einstein Studio in real time in the flow of work. So, inside of your process that you've implemented in Flow, you can call that predictive model to retrieve a value on the fly.

These predictive models can actually be called through from data transforms as well. So, as you're bringing data into data cloud, you can do predictive values and then put the output of those predictive values into your model, your data model objects in real time or in batch also when you're doing the data ingestion.

Okay. And then, how Data Cloud and Agent Forest work together. I've kind of mentioned a few of these places but we also, over the last year, you may have heard the, you know, for our vector database. So, you can bring in unstructured data into Data Cloud with a variety of ways. We have, you can bring in data, unstructured files that get ingested into our and do a vector search index over them for, you know, semantic queries against unstructured data.

You can do that through, all of our connectors for, Cloud Storage like AWS three, Google Cloud Storage, Azure Blob Storage, that kind of thing.

But there's also a new feature inside of Agent Force that you may have seen called Agent Force Data Libraries.

So that's actually a configuration that you're doing in Core Salesforce, in Agent Force inside of your agent configuration where you're dropping files, PDF files, things like that into your data library.

What that actually is doing under the covers is that it's ingesting that file into data cloud, creating a vector search over it so that you then can do a semantic search from your agent from prompt templates, from Flow that might be feeding into Flow actions.

Right? So, you probably know Agent Force by now but, you know, agents have, agents have topics and then topics have a set of actions that they can perform. So those actions can take the form of a Salesforce flow, an Apex class, it can be an API call out to any other system, right? So, any of these mechanisms, any of these types of actions can query data cloud data directly through the common metadata, right, that we have access to from that Salesforce org. And this includes any of the orgs that it can be the home org, it can be the companion org in your Data Cloud One configuration.

Right? So, the other pieces where Agent Force actually required for Data Cloud, I mean, Data Cloud is actually required for AgentForce is operationally.

So, anytime you're going, you're making a prompt template execution that's going out to an LLM, It's calling, through the Einstein trust layer. This Einstein trust layer, you can configure to log all the requests and responses coming back and forth from them into Data Cloud. It's called Einstein Generative AI Audit and Feedback. So, anytime you do a feedback also from an agent response and you do like a thumbs up or thumbs down for the response, that's stored inside of Data Cloud as well. So, you can do analytics on it. You can do, it can help you refine what the prompt template is actually doing so it can actually make it more accurate if you go through and do the analytics on that.

And then Einstein Studio is required if you wanna do bring your own LLM. So, if you wanna point to another LLM that you're hosting on prem in another system like Amazon Bedrock, you have to use Einstein Studio inside of Data Cloud, register that foundational model as an endpoint inside of Einstein Studio and then it becomes available that you can use it inside of a prompt template.

Right?

And then also when you're doing the ingestion of the vector search, so if you're ingesting unstructured data inside of Data Cloud in that vector database, what's called a retriever gets created for you. That's actually a retriever registered inside of Einstein Studio. You can build custom retrievers that are registered in Einstein Studio and then those retrievers are then available from both the home org and any of the companion orgs inside of your data Cloud One configuration to ground prompts to drive actions inside of Agent Force. All right.

So, I'll get through this and I'll take maybe a pause for some questions.

So, I wanna talk about some considerations around setting up your org strategy for Data Cloud. All right, so the first thing that you have to do is decide what Salesforce org. So, if you have multiple orgs and you wanna go forward with this Data Cloud One configuration where you have companion orgs feeding off the same data cloud instance, you first have to decide which org is your home org.

And then, and that has implications, especially for larger customers that have many cell source orgs, right? So, first option, a lot of people immediately kind of gravitate towards is they'll take whatever the biggest Salesforce org that they have, like maybe their sales org where most of their users are living and make that the data cloud homework.

So, all the data you just have to remember that all the data cloud admins that are doing the configuration for data cloud, bringing in data from external sources, maybe Snowflake, this kind of thing, are living now inside of that Salesforce org as an admin. And any of the admins in that org can actually make themselves data cloud admins and then start doing data cloud configuration.

Right?

Another option is you can spin up a whole new org and make that just a dedicated home org for data cloud. A lot of customers, larger customers that I work with like this pattern because you're reducing your risk in terms of like what people are doing in security around how you're developing your data model, how you're bringing in data from all your external sources and multiple Salesforce works potentially, right? So, then the Data Cloud admins only live in that particular org. They don't actually even have to be users in your line of business orgs, right?

Now what's happening inside of Data Cloud when you're configuring your Data Cloud data model, So only the admins in the home org, wherever that home org lives, has access to create the data streams, to create the data model, do all the configuration around security of it as well.

And everything I've talked about so far in terms of like the capabilities in your data model, data cloud, land in what's called a Dataspace.

So the Dataspace is kind of a separate, you can do row level filtering into a Dataspace if you like.

And then what's happening, so data spaces are, so you ingest the data from all those sources in those previous diagrams.

That lands in your data model inside the data cloud on the left. That's the kind of the entire population of your objects and your records. So, at the record level and object level, you can filter those into each individual Dataspaces.

Common things are for Dataspaces or for different business units, for different regions, that kind of thing.

And then the applications inside of your Salesforce org or the marketing segmentations, that kind of thing, are only running on those individual Databases for those business units or in that region, right? So, what that means for Data Cloud configuration in Data Cloud one is that your admins for Data Cloud are dictating which Databases are shared with the companion orgs. So each business, line of business org that is running in your data cloud configuration has access to one or multiple Databases.

And then in the future, those are read only data at the moment. So your admins inside of those companion orgs are only getting read only access for doing configuration for what related list they're showing on the page, for flows that are retrieving data from agents that are retrieving data from data cloud, that kind of thing. But it's only read only. In the future, companion org admins will be able to do things like build marketing segmentation, build calculated insights but they never will be able to actually ingest data from multiple sources, to set up data streams and set up the data model themselves. They can just use what the data cloud admins have given them.

Now also, the companion orgs are, the admins can then dictate permission sets for what users have access in those orgs, for what Databases they have access to.

We also have this policy management that's coming on top of the Data Cloud Platform.

I've already kind of talked about Databases.

We have this new feature, two new features that are coming in summer release of Data Cloud that allows you to do tagging and classification of all of your data model. So, at the object and field level inside of your data model, you can define sensitivity levels like this. So, you can define tagging at the, you can do similar things inside of the core Salesforce objects. Now, you can do this type of sensitivity, tagging, classification.

You can build your own taxonomy for classifications like that are based around application domains, this kind of thing. And you're applying that to your object model inside of Data Cloud and then on top of that object model, you can define security policies inside of Data Cloud. So, this is giving you access to define security, allowing and restriction policies at the object level, field level and row level across your data cloud data model. This is very important especially, I mean, for a lot of reasons, of course, but if you think about bringing in data from external sources like zero copy from Snowflake, from Red Shift, that kind of thing.

This is effectively giving you a mechanism to define what Salesforce users have access to at the row level coming from those external sources that are being honored at execution time. So every time you do a query against the Data Cloud data model, these policies kick in for that individual user inside of any of the Salesforce orgs that you have in your Data Cloud One configuration.

Now, where this fits into the Data Cloud One config that I was describing or org strategy, right, is that, now, you know, wherever the home org is, the data cloud admins can provide maybe course grained security policies across the data model. They dictate the tagging and classification on the data model and then the companion org admins can then further create their own security policies that maybe are more fine grained user policies for the users to specifically inside of their org. So, this is actually a very nice pattern for, you know, locking down your external data inside a data cloud across, you know, this kind of configuration for multi org environments.

Alright. So, other things to know about. So, I have a lot of larger customers like I was describing.

There's a very large biotech company that I'm working with right now that has, a lot of cell source orgs that are inside of different regions in the world, right? So, this company is based in Switzerland.

They definitely would have a separate data cloud instance with multiple Salesforce orgs feeding off of it in a data cloud one configuration.

Then they have another big presence in the US, so they would have a US data cloud tenant for, you know, data residency requirements.

Right? So, what we have coming out just next month, it's very soon, that zero copy technology that we have, we actually are providing data cloud to data cloud tenant zero copy. So one data cloud instance in the US, maybe, you're organizing all your data from your own Snowflake instance here.

You can create a data space that's specific to the objects at the row level that you want to share with a different organization in a different part of the world, you can do that with this data cloud to data cloud zero copy data sharing, in completely different regions.

All right. So, I know this is kind of a heavy content. There's a lot of topics that I've talked about. I'd like to just take a breath for a second before I get into the DevOps part of it because it is a little bit more. So, if you look at this picture here, ultimately what you're doing is DevOps around potentially agents running in each of these Salesforce orgs, feeding off of data inside a data cloud, maybe across different regions, this kind of thing. So, there's a lot to take in, right?

So, now, you know, DevOps for data cloud, this is actually a big part of what I presented on last year, if you came.

So, data cloud configuration and agent force configuration follows essentially the same large pattern of DevOps or Salesforce in general, right? So you configure things through the Salesforce admin. For a Data Cloud, it's actually the Data Cloud tab that you're doing your Data Cloud configuration in.

You can deploy pieces of Data Cloud configuration through the metadata API. The metadata API supports Agent Forest components. This is, you may have seen what Gearset's doing in that front.

And then deploying with packaging. So, there's actually a new container that Data Cloud brings along for packaging. It's called the data kit. So, all the components for your data model and all the other configuration that I've kind of talked about, You can package into a data kit and then that data kit can get put into a chain set or a package of any kind, second generation packaging, unlock packages, this kind of thing. And then you deploy the data kits to a different environment.

I'll talk about that in a minute. But, so there are some differences, with data cloud deployments than you are used to in just normal Salesforce land, right? So we do have, so as of October last year also, we have a Data Cloud sandbox, which is good, finally.

So, this allows you, so the way that Data Cloud Sandboxes work is you take your normal Salesforce org. So, say you have your Salesforce org that is your home org, whichever one you decided is gonna be your home org. That home org has a data cloud tenant tethered to it. When you spin up a core Sandbox from that org, it can be any type, right? It can be a dev Sandbox, partial copy, full copy, doesn't matter.

But what happens is that if that is a Sandbox from the homework, it will automatically have a Data Cloud Sandbox tenant created underneath it. And then that core Sandbox then becomes the homework for that Data Cloud Sandbox. So, this is generally just how Data Cloud Sandboxes work.

Now, what you're then doing is you're configuring your Data Cloud Sandbox.

Any of the things that I talked about work inside of Sandbox. So you're configuring, maybe you're building your agents in that Sandbox that is doing vector searches, across data that you ingested from S3, something like this, right? So you do whatever you want inside of that configuration.

And now there are dependencies that you have to take into account, that you didn't have before with normal Salesforce development, right? So, anything that is dependent on Data Cloud now, for your agents or anything else that you're doing for CRM enrichment, that Data Cloud configuration needs to be promoted to your production environment first And then you can deploy your metadata from your agents and any of the other components like flows or something like that that are retrieving data from Data Cloud. So, it's a multi step process.

And then we also have a variety of ways to doing configuration for Data Cloud.

So all those things that I mentioned, there are still some pieces that you have to go in manually inside of the Data Cloud app inside of your org to configure.

You can, of course, package up the data kits so all the components and data kits deploy them through chain sets work from your sandbox into production.

But then data kits are actually, kind of work like this though. They're different than normal metadata, right? So, you're taking all those components that I've talked about, you're putting those into a Datakit. So, these are my data streams, these are my data model objects, the mapping to them, calculated insights, any of that kind of stuff, right? You're putting into a data kit. And then you're putting those into either a chain set for promoting into your production environment or you're putting them into a package that you can then promote via all the ways you can promote packages, right? Through the CLI, through API, through the UI, you know, for just pointing to packages, that kind of thing.

But what you're doing is you're just providing that metadata is getting copied into that new data cloud tenant but it's not configured. It's just there sitting there waiting for you to actually hook it up. All right. So then what you have to do is if you're, you can go through the UI and point to things like if you go into a data stream and you have a data bundle that you put in your data kit that provides the data streams for your S3, for Snowflake, this kind of thing.

You have to still go into the admin and go, I want a new data stream. You point it to your data kit and you pull in the objects that you want to pull in for that data stream and then the data stream's live, right? You can do this programmatically through a new flow that we have called it's a new flow type.

It's actually a normal flow inside of any Salesforce org. It's called Deploy DataKit Components.

So, this actually allows you to, through the normal Salesforce API, kick off this flow, tell it which DataKit to use that you've deployed previously and then sequentially do the configuration from the data kit components, in that flow and it's like a long running process that runs that will do things like, so it'll set up the data streams, set up the data model mapping.

You know, now that you've got those data model objects inside of your config, now deploy the calculated insight that relies on it. Right? Now deploy the segment that relies on that data model object, that kind of thing, right? So, you're doing a, you're issuing a sequence of steps for doing the actual configuration and you're doing this through this special flow that we have now.

So, if you look at, so this is to, everything I just showed you was from like, you know, starting from scratch with a new Salesforce implementation.

There are some nuances for, that are just good to know about for existing implementations. So, if you've already done a first deployment, you did your configuration and production for a data cloud.

Now, if you do a Sandbox from that implementation, it kinda works the same. But the difference is, any of the connections that you had to any existing Salesforce orgs for like a multi org configuration, for any of the external services. So any connector that you've configured inside of that production data cloud tenant, the connection definition will be there in Sandbox but you have to re authenticate those connections to the lower environments for the data streams to start working inside of Sandbox.

Right? So, you have to, hopefully, if you're doing data from your Salesforce orgs, you would spin up equivalent Sandboxes for those orgs and do re authenticate your CRM connection to those orgs, the Sandbox orgs so you can start ingesting data from them.

Hopefully, you would be doing lower environments for like a different S3 bucket or something like that for test data maybe, this kind of thing. But, so you're reconfiguring the connections but you have all the metadata from Data Cloud.

Just like Sandbox is working core in that sense but you have to reauthenticate the connections for the data streams to actually start working again inside of your Sandbox environment. So then you go through your build, whatever you're doing different and then you have to go through the same process, right? All the things that I talked about are still relevant here, right? This is just for completion, for showing you what you would do. Now, multi org environment, kind of the same thing. You might have multiple Salesforce orgs and then you want those connections in Sandbox to be pointed at Sandbox, the equivalent Sandboxes for those core Salesforce orgs that you're bringing data in.

And then lastly, for Sandboxes for Data Cloud one configuration, right? So, you, of course, want to mirror what your production is for your lower environments for a Sandbox environment.

So, works kind of the same way that I've been talking about, right?

But now what happens is that if you have Data Cloud One configured, so you have companion orgs configured inside of production, Those CRM connections for those companion org connections are disconnected and lost inside of the Sandbox similar to all the other connections.

So, you'll have this picture here when you have your initial Sandbox.

You'll want to spin up Sandboxes for both of those orgs or any of the orgs in your environment and then reconfigure the connection for both the connections for the external sources and the CRM connection for the companion org for your Data Cloud One configuration inside of Sandbox.

So, these are all the things that you have to think about for actually doing a mirror, you know, Sandbox for your production environment for a Data Cloud One configuration.

And then of course, now, once you have, so I work with a lot of customers that are, you know, they're trying to do workshops, they're trying to do POCs, they're trying to do hackathons in their own environment.

But they wanna do it in a Data Cloud One configuration because that's what they're gonna be doing in production. So, this is actually what you have to do, right? You have to do all this stuff. Now, your developers inside of the Sandbox can build their agents in a manner that's gonna be consistent with what they're gonna be doing in production for a Data Cloud One configuration.

There are a bunch of nuances that I'm not gonna talk about here because we don't have time. But if you're considering doing this, I would urge you to reach out to me and I can help you through it. This is what I do on my day job is helping people figure out what their work strategy is, how they're gonna go forward with this kind of topology.

Now, the other part of this, right, is that inside of a Data Cloud One configuration, you have an additional step too, right? So, not only do you have to merge, you have to push, you have to promote your data cloud configuration into prod. Now anything that you're doing in either the home org or any of the companion orgs, those are a separate process as well, right? So those are normal metadata that you're deploying from that core Salesforce org to the core, to the production home org or from each companion org to the equivalent companion org inside of production, right? So you have additional steps to take into consideration when you're defining what your process is gonna be for deployments for Data Cloud and Agent Force.

So, I know that was a lot of content to get through, a lot of topics.

I do have a few minutes for questions.

I have, this presentation, I have available publicly.

I know that we share it, or shares them from the conference but you can get to it directly from this QR code if you like as well.

So, questions?

There is a process that you can follow to turn it off if you really wanted to. So, what you're talking about is that, you know, Data Cloud one really means that you've got companion orgs, right? So, if you had oh, sorry. That was my timer. So, if you have a, a companion org configured, ultimately what's happening is that some of the metadata from the data cloud tenant, like what you've shared in your data space, is actually gonna be replicated into that org. Right? That's how the metadata is stored inside of the companion org and the homework.

If you decided that you didn't want that to be a companion org for whatever reason, you have to submit a case. Our engineering team can deprovision, the metadata from that org and disconnect it from Data Cloud if you really wanted to. Right? Yes.

Yep. So, there's a process that you can go through.

I'll tell you this is kind of hairy, right? Because if you've done anything that depends on Data Cloud now from like a flow, from agents, that kind of thing, you actually have to back it out, right? You have to delete that configuration that is relying on those data cloud objects, right? So, you have to do that first and then we can deprovision you and then it can be connected to another at that point, it can be connected to a different data cloud instance.

It can become a homework at that point if you wanted to, that kind of thing. Yeah. Good question. Yeah.

Yeah.

Yeah. So, the access so the security policies that you can be so that, by the way, is in beta right now.

So you can get it enabled in your org to play with and it goes live in summer.

The way that that works is that, you're defining that at the Data Cloud data model level, and those will be honored from anything querying Data Cloud, right? So, any application so, if you have a flow inside of your Salesforce org, that flow is running under a user context.

If it queries Data Cloud objects, the security policy will be applied at that point and honor the user permissions that you've set up for the security policy and then the policy will execute, right? For like restricting access to certain fields or objects or row level security at that point. And, the security policies operate at the API level as well. So, if you're retrieving, what that means is that regardless of where the applications are that are retrieving data from data cloud, the security policies will be applied at the time of execution for the query. So, that includes things like Tableau, very important. Right? So, if you're building a Tableau dashboard off of Data Cloud data from all the external sources, you know, the user that you are inside of Tableau, that security policy will be applied at the time that this dashboard is refreshed for the data that's getting pushed into that dashboard.

So, it operates the security policies are honored at the API level regardless of the application feeding off the data. Yeah.

Good question.

All right. Anything else?

We're a little over time, but I know we're just on lunch break now. So, I can stick around if anybody has questions or, find me a lunch. So, thank you very much.