[Music] [Martin Rauchwerk] Hi, everyone. Welcome to our session, Adobe’s New Tools: Empowering Third-Party Developers. My name is Martin Rauchwerk, and I'm joined by Mayanka Sharma. Together, we manage Adobe Exchange, the marketplace where partners can publish application extensions to Adobe products and make those accessible to our customers. By the end of this session, we hope you will walk away with an understanding of server-to-server integrations, as well as the end-to-end workflows for a partner to create an application and distribute it on Adobe Exchange. This paves the way for Enterprise customers to discover, download, and self-install applications using their Enterprise credentials. There are four tools we'll highlight in this presentation, the Developer Website for documentation, the Developer Console for building applications, and the Developer Distribution for creating listings to be published. Finally, customers will use Adobe Exchange to acquire and manage their applications.
Mayanka, can you please provide some context? Why are server-to-server integrations the future of a seamless customer experience? [Mayanka Sharma] Hi, everyone. I'm so glad you said seamless customer experience, Martin, because as Steve Jobs once famously said, "Customer experience comes first and technology is its enabler." At Adobe, we believe and practice this philosophy in everything we do. So let's start with why we are talking about server-to-server integrations today.
Digital landscape is continuously evolving, and more than 14,000 marketing technology solutions exist today catering to it. What's even more mind-boggling is that this number rose by almost 30% in 2024. So on average, medium to large organizations are using 5 to 10 such tools, and they all need to talk to each other. Why? Because end-customers of these organizations are digitally savvy now, and they demand unified experiences. They don't care about the plumbing behind the scenes. All the content and data across solutions must talk to the customer as one.
Server-to-server integrations enable that. These are API-based integrations between two or more servers, which essentially exchange data protected by security mechanisms like OAuth authentication.
The data exchange happens completely between the servers. And so the beauty of it is that these information exchanges aren't visible to individual users. For example, when an end customer wants to purchase something like a dress or groceries online, they place it in their cart and check out. They aren't aware of all the plumbing that's required to make the experience seamless. Behind the scenes, multiple systems talk to each other, such as inventory management tools, a payment gateway in order management system and order fulfillment system, and more.
There are thousands of such use cases depending on the industry and business needs.
Adobe Exchange has 275 public server-to-server integrations that extend experience cloud products, but these are mostly catalog listings. This means customers can find them on Adobe Exchange, but need to contact the publisher of that application to directly acquire them. Mayanka will introduce a new feature that will enable developers to publish server-to-server integrations that can be acquired from Adobe Exchange without having to contact the partner directly. Let's take an example. RainFocus currently has five catalog listings on Adobe Exchange, we were the early adopters of these new workflows.
RainFocus is a great example, and we'll be using one of their integrations to show the new workflows. So RainFocus is a platinum level partner with Adobe. We have worked with for a long time. As a leading event marketing platform, RainFocus differentiates themselves by seamlessly integrating event experiences into marketing opportunities. One of the integrations that helps them do this is their RainFocus Source Connector application.
This connector allows their customer organizations to flow event data from RainFocus servers into Adobe Experience Platform enabled by authentication. Once data starts flowing in, customer organizations can create personalized experiences driven by attendees' interactions. For example, using RainFocus enriched user profiles flowing into AEP, mutual customers of RainFocus and Adobe Campaign could target and convert leads gathered during these events into customers with personalized content. Today, this connector by RainFocus is listed on the Exchange Marketplace.
What gaps and pain points exist today that we can solve in the current marketplace experience to enable each partner to deploy their integration to many customers simultaneously on Adobe Exchange? To understand the gaps, let's look at the integration's lifecycle today. It begins with the partner building the integration using OAuth server-to-server credentials on Adobe Developer Console, and then distributing it using Adobe Developer Distribution. The listing gets reviewed by Adobe, and if all is well, it's published on the Exchange Marketplace. Note that these are catalog listings, which means that they have rich details about the integration, but not a lot of action for the customer organizations interested in the integration, like we just saw with RainFocus Sources Connector. So when the customer wants to begin installing the integration, she must reach out to the partner to do it, even if they are a mutual customer for the partner and Adobe.
Customers must also go to Developer Console to create their own credentials and share with the partner, so the partner can configure the credentials in their integration application and access customer's Adobe account. Both these customer actions happen out-of-band. The first challenge is that customer journey has these extra hops, including onboarding and learning about Developer Console, and taking all the steps that a partner takes to create OAuth server-to-server credentials for their organization and sharing them with the partner. Every customer organization must do this. The second challenge is that the partner must manage credentials for all the customers using the integration, including rotation of credentials, which is required for security purposes. The third challenge is that Adobe does not know if the customer who visited an integrations page on Adobe Exchange contacted the partner, or if they started their first steps of the journey to acquire the application. Because of which, Adobe has limited governance on what the third-party applications are doing. To provide the best partner in customer experiences, Adobe needs the ability to monitor how customers' Adobe accounts are being accessed, monitor the health of integration applications, and enable partners and customers with insights on adoption and usage of these applications.
How are we eliminating these pain-points and putting a robust governance system in place? We are introducing new workflows for both our partners and Enterprise customers. These improved workflows are facilitated by the new Enterprise credentials that are specifically being introduced for partners who want to distribute their integrations to multiple Enterprise customers. Here is how we will improve the experience in workflows for partners and customers. Let's look at the partner journey again. The partner enrolls with, or is already a member of Adobe's Technology Partner Program. The partner is informed about how to create integrations with the help of new Enterprise credentials on Adobe Developer Website, the first mile of their journey with rich public documentation.
Using these credentials, the partner will find it easier while building and testing the integration. For example, there will be a playground experience that partner-developers will be introduced to, where they will be shown how to build the consent URL and embed it in a sign in Adobe button in their integration application. So they will be guided to ensure that it's a seamless experience for Enterprise customers and on how to resolve any issues while setting up the new authentication mechanism even before going live. After testing, they will list their submission with the help of Developer Distribution.
Adobe will then review their integration listing. There will be white glove treatment for early adopter partners. They will be supported every step of the way, including email communications and from partner managers. After approval, the application will be published on Adobe Exchange. Next, a customer will discover the integration on the Exchange Marketplace that fits their business needs. Any user or admin in the organization will be able to acquire the listing, but an Enterprise administrator in the organization will need to provide consent on behalf of the organization, so that the integration can access the customer organization's data.
On their consent or approval, the Enterprise credentials will be created, allowing the app access to only the limited set of scopes the integration needs. The authentication journey has become much simpler for both partners and customer organizations. We'll see a visual example of this later.
Cherry on top is that Adobe's product and support teams will have more insights on which customer organizations have installed the applications, what is their usage. And so Adobe will be able to quickly help both Technology Program Partners, as well as Enterprise customers because we can now observe the end-to-end process with proper governance to enhance security. Can you show us the workflows where the partner creates an integration on Developer Console and submits a listing on Developer Distribution for publication? Sure. At a high level, a partner who has already signed up for the Technology Partner Program and read up on documentation on Developer Website begins their build journey on Developer Console when they choose an API they want to use in their integration.
In RainFocus' example, they choose the Adobe Experience Platform API that their connector integration will need to access, so that connection can be established between customers' accounts in RainFocus and in AEP via this API. Like we discussed earlier, the partner was still now opting for server-to-server authentication credential for building their integrations, which is an industry standard authentication mechanism, but which also is designed for an organization to use the credentials for their own integration. So it requires customers to also go through this process of coming to Developer Console and creating their credentials to share with the partner. For the new and improved workflow to cater to the use case of an integration that the partner intends to distribute to multiple Enterprise customers, the partner will need to choose the new credentials that are being launched, called Admin Authentication highlighted here in blue. RainFocus will choose these now as they want to distribute the connector integration to multiple customers. As they choose this credential, they will be informed that the customer admin will need to provide consent to their integration for it to be able to work. This Developer Console screen looks new. What are these redirect URLs that the partner is providing? Previously, we established that the customer admin will need to consent to the connector integrations access, and this will happen through a browser-based consent screen. This consent workflow could get triggered from the partner's integration application itself or from the integrations listing on the Exchange Marketplace. So for the scenario when the consent workflow is being triggered from the partner application, what RainFocus will need to do here is share some redirect URLs that Adobe can use to send the customer admin back to partner application from the browser-based consent screen.
So the credentials are in place now. RainFocus can now go ahead and build the connector integration. Once done, they would like to test it out. They can do so by letting the integration access their own organization and see whether it's working as expected or not. The way the integration will handle and integrate a customer's data.
The partner will be able to generate access tokens for their organization and use them in their integration.
Now what I love about this is that it's not just the partner generating access tokens, they also get what we are calling a playground experience that essentially helps them see and us understand the experience that the customer will have when they are giving the consent. More importantly, it's also a step-by-step guide aided by examples on how to set up and configure the application. So the customer gets back to the application correctly after providing consent and more such useful tips. Let's say that the integration is done and the partner has tested it using the playground experience. The access token is generated and the integration is working perfectly fine for their own organization. Now they want to start distributing it publicly. What's the next step? To distribute an integration, the partner will need to create a listing for it. They can create a listing from Developer Console itself or go to Adobe Developer Distribution, where two types of service-to-service integration listings will be available. One is specific to an AEP Sources Connector use case, like RainFocus' Sources Connector. And the other use case is of a generic multi-tenant server-to-server integration, such as for Adobe Analytics or Adobe Campaign.
Note that sources connectors are also discoverable in AEP Sources Catalog. And hence, the partner needs to choose the AEP Sources specific listing type if they are building a sources connector. The partner will be aided in making the decision of choosing the correct listing type with help of linked documentation on Developer Website. That will help them with when to choose which type of listing.
What the partner needs to do in either case is provide a set of listing details or metadata. For example, good screenshots from inside their application, short description about the app that shows up on search results in the Adobe Exchange Marketplace, categories for filtering, products that the integration supports, all to ensure that the customers look at the integrations page on Exchange and are able to understand what the integration application does, and whether it's a good fit for them. There is also information that the partner will add here to be displayed on the consent screen to the customer. So the customer takes an informed decision after looking at the application's website or partner's privacy policy, for example. For an AEP Sources Connector listing, the partner will also need to add the Git-Repo link for the connector spec, which contains metadata specific to what the AEP Sources Catalog requires.
For both types of listings, the partner is also shown the details related to their Enterprise credentials under the API tab. So they get to see the technical account. Adobe APIs they have added to their integration, the scopes corresponding to those APIs, and more. It basically is interoperability between Developer Console, where they build and test the integration, and Developer Distribution, where they are distributing it. I just love this because the partner doesn't have to go back to Developer Console to double-check if everything is correct before submitting the integration for Adobe Review. Once they fill out the required information, partners click Preview and submit. The partner has additional options on the submission page, such as to ensure they have complied with the brand guidelines, or leave a note to the Adobe Reviewer that helps with the integration approval.
They also can choose to publish the listing right away, or opt to publish later. After doing this, they can submit the integration listing for Adobe's Review. When Adobe's Review teams look at the integration, and they say, "Yes, this is good to publish on the Exchange Marketplace, and also in the AEP Sources Catalog, if it's a sources connector." Or they might say, "No, the integration description needs to be longer, or the screenshots aren't the right resolution, and send it back to the partner." When an integration listing gets rejected, the Adobe Reviewer also provides a note on the reason why it did not pass review, and the reason shows up on the listings page in Developer Distribution. The partner also receives email notification that the integration listing needs some changes.
Now let's say that the reviewer finds all of the details to their satisfaction, and they approve the listing. Once approved by Adobe, the integration listing is published on the Exchange Marketplace, where customers can explore them, acquire them, consent to them, and manage them. Note that AEP Sources Streaming Connectors supported for the new credentials also get published in the Sources Connector Catalog in Adobe Experience Platform.
What will the improved Enterprise customer journeys look like? Well, they look quite different and evolved. The user on the Exchange Marketplace will be able to discover the listing more easily by applying a filter for these kind of integrations while browsing. On the listings details page, the user will see the option to acquire the integration. On clicking, they will be asked to ensure that they have the required Adobe products licensed to the organization for the integration to work for them.
Adobe Exchange will then also check if they are logged in to an Enterprise organization. If not, they will be prompted to try logging into a different organization. If they do belong to an Enterprise organization, the integration will be acquired for the organization. What's important to note here is that though any user can acquire this integration, it requires a role with much higher privileges to go any further. So if the user acquiring the integration isn't a system administrator in their Adobe organization, they will be informed that the admin only can take the next steps of providing consent to the integration on the organization's behalf. They will also be guided to where the admin might find the integration once they log into Exchange Marketplace. The integration will be acquired. Once acquired, the integration will start showing under the Manage Experience of Exchange Marketplace, visible to every user who logs in with that organization, while only admins will be able to take certain actions, which we will talk about shortly. The Manage page will also show the list of all integrations that have been acquired by any user or administrator in that organization. When were they acquired, which Adobe products they work with, their status, and actions that can be taken for each integration. Now that an Enterprise user has acquired an application, can they begin using it? No, not yet. First, the system administrator needs to provide consent. So the application is authorized to use company data. On acquisition, administrators will receive email notifications informing them about it, and that admin consent is needed before next steps of installation can be taken. An admin logging into Exchange will see the list of all applications acquired by the users in that organization. So let's say that the admin of the customer organization wants to consent to RainFocus Sources Connector integration. They will click on Begin Installation. The click will launch the browser-based consent workflow. Note that this page is only accessible to Enterprise administrators logged in, and hence has a higher level of security. So apart from allowing them to approve access for the integration, the screen will tell them, "Hey, RainFocus Sources Connector is the name of the integration you are consenting to." They'll also see their Adobe organization's name, so they can be sure they are logged into just the right one.
And very importantly, the admin will also be shown what exactly it is that they are allowing the application access to for their Adobe account. As a simple example, let's say an Adobe API allows RainFocus' connector integration to access event attendees' basic profile information. It'll show up here.
If all looks good to them, they'll hit Allow access. With this, their consent will be registered with Adobe, which means that a connection has been established.
Can you now show on the Manage tab how customers manage applications they have acquired? To manage, you need to have all the information you need. So there will be a variety of details showing on Exchange. For example, information about the integration listing, as well as about APIs and the corresponding scopes that the integration will have access to. Additionally, key actions that have been taken by the user or admin will show up here, such as when the access was granted to the integration, when was it acquired, and who did these things. There will be the option to access documentation and also the support information provided by the partner, and an option to mail the partner support right from Exchange. There will also be a link to Adobe Admin Console where admins can explore more detailed activity logs. Also, very importantly, admins will have more control on what the partner app can access right here on Exchange, where they will be able to choose product profiles. A product profile is something the admin can create in Adobe's Admin Console and add users and user groups to it. So product profiles help assign more granular level access to the exact features that the integration will have access to. Can Enterprise administrators revoke access they previously granted? They absolutely can. This is an important governance feature for Enterprise customers to be able to take back access to their organization's account in few simple clicks. How do they do it? In the same Manage Experience on Exchange Marketplace, the admin can click on the Revoke access option at any point after assigning product profiles.
When an administrator clicks on Revoke access, they will be asked if they are sure and to repeat the application's name to avoid accidental revokes. What's important here is that it will be made clear to the admin that the integration will no longer have access to their organization's Adobe account if they go ahead with the revoke. On confirmation, the revoke action will be enforced within an hour. The Manage Experience will also start showing who revoked access and when.
The admin can unrevoke anytime by consenting to the integration again.
What is now available and what will come later in 2025 and beyond? The good news is that everything we discussed is live today. We're also working on getting in more features such as enabling partners to test with a select set of customer organizations before publishing the integration. Allowing API and scope updates to the published integration listing along with richer insights into integration adoption and usage. We will be designing future features based on partner and customer feedback in the coming months.
Thank you. Thank you, Mayanka. That was great. Calling all partners. Please contact us if you're interested in creating a new server-to-server integration with Enterprise credentials, or if you already have an integration listed on Adobe Exchange Marketplace and would like to onboard the new credentials. Also, contact TPP support if you are a customer and have a use case that you need to solved by a partner. Thanks for listening.
[Music]
