Initial setup and configuration

Transcript

All right, can everybody see my Workfront screen right now? So I have a customized dashboard here in my Workfront environment, you may see. All right, so I’m going to start here, actually, I’ll jump over to AEM first. So what we’re going to demonstrate really is the configuration of a connector. And once it’s installed, we’re going to be primarily focused here in the cloud services of an AEM environment. So this will be the same, regardless of the deployment flavor that you’ll be working with. So whether that is a AMS, Adobe Managed Service Environment of 6.4 or above, as well as a self-hosted AEM deployment flavor of 6.4 and above. And then also we’ll be talking about some of the nuances between an AM as a cloud service environment as well. So this is the Workfront for Experience Manager configuration that we’ll be discussing. But prior to jumping into that, I’m going to just pull up some of the Adobe docs. So I’ve pulled up both of the Adobe Experience Manager assets integration for Workfront and the difference between installing this in the cloud service environment and some of the things that we just need to be aware of here. But to start, a few things that I want to walk through as it relates to installing the connector in any of the deployment flavors. So really the first step when we engage our customers for a connector install is figuring out what deployment flavor of AM they’ll be working with and are there any firewall configurations that we need to take into consideration. So as many of you may know, in a typical Adobe Managed Service deployment of Adobe Experience Manager or a self-hosted deployment of Adobe Experience Manager, there is several firewall considerations including a dispatcher layer in many cases. So for those AM environments, we need to take into account the dispatcher. Many of our clients that we work with in AM have specific rules at that dispatcher layer that sits in front of the AM author environment. So the dispatcher may be configured in such a way that it only allows for certain calls or requests to be made. So we have to make sure that we’re working with the right technical folks at our clients’ organizations to determine what are those dispatcher configurations and is there anything that we need to do or any items that we need to add to those allow lists at the dispatcher level to ensure that all the calls to and from Workfront and AM are successful. So we add here in our notes prior to any install is that we ask that our clients ensure that their dispatcher allows for the HTTP headers for authorization, username, and API key and that a get, post, and put requests are all allowed to that path here. So that path is really pointing to our connector servlet that will manage all of the calls on the AM side. So as long as that’s set up from a firewall perspective on the AM dispatcher level as well as any further firewall configuration, so it’s common to see an Akamai layer, for example, sitting in front of the dispatcher as well. So many of our larger enterprise clients may have additional security layers in front of their dispatcher that we have to take into account. So assuming we’ve configured that on the AM side, we also need to ensure that the client has added any of the Workfront IP addresses based on their Workfront cluster to their allow list. It’s often the case that our customers may not have an allow list set up for their AM environment, meaning that any of those calls will make it to the AM author environment. So there are sometimes, and I think this becomes more common with our AM as a cloud service customers, that there is no allow list in place. So any of those calls from the Workfront environment are going to successfully make it to our AM author environment. Just in case, one of the things that we share with them is all the IP addresses. Let’s see if I can have it pulled up here.

I might have the wrong…there we go. So on Workfront, our 1.Workfront, there’s a list that you can find based on the cluster that the client’s Workfront instance belongs to. It’ll list out all the IP addresses. Just working with the customer to identify or the Workfront account rep to identify what cluster they belong to, and then we share with them the list of IP addresses to add to that allow list prior to the install.

I sort of went backwards here, talking about the Workfront firewall configurations first, so adding those IP addresses to the allow list, setting up the AM dispatcher and any other layers that sit in front of that AM author environment so it’s configured correctly. So it’s really working with the customer to ensure that they understand what’s required here and they involve the right technical resources on their side. And that may be an implementation partner or they have an in-house technical support team to do that for them, but that is required prior to installing the connector.

And then we have the next step is really identifying the specific paths within our connector that they need to take into account. So as you know, Adobe Experience Manager, there are many customers who have… many clients who have customized their environment, meaning that they may have some custom overlays that override the path that you see here. So here on my screen, these are all the specific paths that our connector code will apply to their AM environment. So this is what customizes their AM environment in a way that they can use the connector. So I would say this happens less often, but just something that we call out for any clients that we work with, that if they have existing customizations at these specific directories. So for example, here, let’s take this as an example, this folder metadata schema editor. This refers to an AM when your customers are building custom metadata schemas at that folder level. We have a specific overlay that applies a work front metadata mapping feature. And that mapping feature allows us to map work front custom form fields at any object level. So agnostic to the object type, really any of the custom form fields found in the custom form library in their particular work front instance. We can map to the any custom fields that get created on the AM environment. So we have, again, this happens less often, but we have run into situations with customers where they may have already customized the folder metadata schema editor, and they have applied some custom element to their AM environment. So we just need to be cautious and work with those clients to identify if there are existing customizations that we need to take into consideration, and then work with their development resources to ensure that we take those conflicts into account and we merge the code safely. So normally, it’s not an issue and we have a way to work with each customer to do that. But we just want to make sure that they’re aware prior to the install so that when we install this connector, they don’t open their AM environment and find out that their custom code is missing. So next, jumping down to the installation. What we recommend in all cases, whether you are a self-hosted AM deployment, Adobe managed service, or AM as a cloud service, that the connector is installed as a dependency of your palm.xml file. That’s not to say that if there are customers that want to download a package for testing, it’s more applicable for Adobe folks that are demoing the connector or quick spin ups on a local environment. What we’re recommending to our customers is that if they plan on installing this, that it goes to the proper pipeline and it’s installed as a dependency of their Maven project.

We’re going to jump over to the configuration now and we’re going to pretend for a bit that we’ve gone through that install, whether it was adding as dependency or that you had a local development environment using the cloud service SDK on your client device. And now that it’s installed in your AM environment, we’ll pick up from there and walk through the configuration steps required. All right, so I’m going to come over first to my AM environment. So I’ve set up an AM environment here. Again, we’re assuming that this has been installed and the package, whether that was done through a local SDK as you’re doing local development or you’re planning on doing a demo, or if you add this as a dependency to your Maven project, you then will come here. We’ll start here at the main screen. So you’re in AM assets, come to the top and select the Adobe Experience Manager home button, and then come down to the tools interface. And you’ll see here on this panel, just to make things a bit more confusing, this is cloud services, which is not the AM as a cloud service. This is just where you’ll find many of the different integrations like dynamic media and Marketo. So along with all those other integration configurations, we’ve included the Workfront for Experience Manager configuration dialog on this screen as well. So once installed, you should see this Workfront for Experience Manager configuration here.

If we click on this here on my screen, I already have one pre-configured. But what you’ll see when you click on the Workfront tools menu here, and this is just some AM knowledge, these always show regardless of the integration you’re working with. So if you’re configuring dynamic media or the Marketo integration, these will show up. So just be cautious that you’re coming and selecting the Workfront tools. Because if I click to any of these other ones, you will see this create button, but that’s not the correct space to create the configuration. So ensure that you’re at the Workfront tools, and then you’ll have that create button. And then that will open up to this screen here.

So I’ve already configured in this environment, but I’m going to walk through the steps that I did. So everybody’s on the same page as far as how this is set up.

So when you come in here and this hasn’t been configured, what you’ll see is a blank screen here without the credentials populated. But I’m going to walk through what we’ve done for each one. So the first step is giving it a configuration title name. And the important thing to note here is this is the configuration title. The configuration title name is the same name that will get applied to the document provider custom integration that gets set up on the Workfront side. So just know that setting the name here is important in order to identify the correct document custom provider that gets created in your Workfront environment. So I give it a name, and then my next step is taking my AEM API endpoint domain. So that’s really just the URL to my AEM API endpoint. And all I have to do is take that URL from, I don’t need to add any additional paths, just the main URL and populate that here. So I’m just pointing to the Workfront environment, and it will append the rest. So the system, the configuration actually adds this slash bin slash Workfront tools for us. So there’s nothing that we need to add there additionally. And then the second step is pointing to your Workfront domain. So this could be a with a lot of our customers when we’re doing this in a initial install, we may install this in the sandbox environment or preview environment first prior to moving to production. Again, one of the things to just be aware of there is that knowing how the Workfront sandbox refreshes work is important. So if you’re looking at a work front, you’re looking at a work front, you’re looking at is important. So if I were to configure this in a production or in a sandbox environment, and I set up my configuration details, and then somebody has a or the client has a refresh scheduled for every Friday at midnight, we may lose some of the configuration details in our Workfront environment. So that’s just something to be cautious of as we’re configuring in sandbox or preview or in sandbox environments in Workfront. So for this example, I’ve just configured it to my Workfront production instance. So I just put the domain of my Workfront production.

And then down here, the username and password that it’s requesting is a system admin level Workfront user.

So what we will recommend our customers to do is to set up a service user. And what I mean by service user is just setting up a generic user that is responsible for handling the integration. So we’ll work with clients and we’ll say this is the Workfront tool or the Workfront connector user. And we’ll give that user system administrative privileges.

The important thing to call out here is that that username and password never once the initial connection is established, am is not saving that username or password at all.

Rather, it’s taking the username that administrative username and password, establishing the connection through that username specific API key. So to show that quickly, I’m going to jump over to the Workfront environment. And as if you are logged in as an admin user in your Workfront environment, and you come up to the nine box grid, the setup window, and then come down to your system settings down here.

And you look at your customer info. This is the API key that we actually authenticate. And we encrypt to use to establish connection after that initial motion of connecting to the environment. So again, we’re not saving the admin username and password all on the AM side just for that initial handoff in order to get access to that user’s API key. And then we use an encryption service on the AM side to encrypt that API key. And that gets stored in the AM environment in order to handle the authentication for all the actions of the Workfront connector.

And the reason I like to call this out in my demonstrations is because when it comes to troubleshooting customers, Workfront connector related issues, it’s often the case that you may find a customer who comes up here and they have this set to say three months. So this is a system setting that every three months, the user’s API key will be will expire or refresh. So a new API key will be set for that user. And that’s important to know because we’re using that initial API key during the connection.

And we’re storing that encrypted on the AM side. So at the end of this three months when that API key refreshes, we may see some issues with the connector not being able to successfully pass documents and metadata back and forth. And all we have to do at that point. So again, it’s not it’s okay that the customer has their API keys reset if that’s something that they choose to do. What we just need to be aware of is that after it’s reset, we have to just come back in here and reconnect. And reconnecting, putting in their password and selecting the connect button will actually grab the new API key and store it encrypted in AM as well.

And then the last thing I wanted to mention here is that when we select this connect to Workfront button, we’re actually using the Workfront APIs to automatically create the document custom integration in the Workfront environment.

So what that means is that you won’t need a Workfront system admin necessarily to come into Workfront and set up a manually set up a document custom integration. So at the time that I hit connect, this is the custom integration that automatically gets created in your Workfront environment. And it sets it up as an API key authentication type rather than an OAuth authentication type. And then that API key down here, this is what gets auto-generated and then passes to authenticate that document custom integration.

So just to recap, everything needed to establish the document provider custom integration between your AM environment and your Workfront environment can be done here on this screen.

Any questions on the initial configuration steps? So that admin user, that’s a serviced user in AM that we’re creating for the Workfront connection.

We have a serviced user on the AM side for the initial setup. And there are some actions that require the serviced user on the AM side as well. But this user in particular, so the username and password that I put here is typically going to be a serviced user on the… And when I say serviced user, just to be clear on the Workfront side, there isn’t like in the AM world, there isn’t a specific serviced user. I just mean that create a generic user so that the clients when they’re using the connector, they know that that system admin user is being used for this particular connection. So it could be something like this, and this would be a Workfront email address. So this would be like your Workfront login for that admin user. But there is, I mean, to your question, there is a serviced user that gets established when the package or when the connector is installed in an AM environment as well. And we’ll talk about that here shortly. But that service user is only used for a couple of actions, sort of the base foundational elements of the connector. And then there’s actually going to be an individual user created in AM for every Workfront user as well. But we’ll get into that a bit more.

The last thing I’ll point out here as well is that anytime you need to regenerate an AM API key, so let’s actually I’ll just step through that real quick. So if I wanted to just regenerate this AM API key, I’m going to get a success message here that said my Workfront custom integration has been updated with the new information. So just clicking this regenerate button will actually make a call to Workfront. And so we’ll see this API key ending in TTS. If I come into this, we should see that that API key has now been passed over here to the Workfront environment. So anytime that you want to refresh or regenerate an API key for the Workfront document custom integration, you can do so from that AM configuration dialog and just regenerate the API key there.

JAMES WELLS-DALYK One last question on the API keys there, I may have missed it, but you had showed in the system info and Workfront those API keys that are, are those the same as what is being passed here? JAMES WALLACE-WELLS-DALYK No, and that’s a great question, James. I’m glad you bring that up because this is something that took me a minute to wrap my head around as well. So I’m glad you’re asking. And I don’t want to confuse anything here, but it is important to understand the difference between the two API keys. So this is an API key that belongs to your Workfront environment.

This API key exists for even, you know, Workfront customers that don’t have the connector. You’ll see this here, and it can be used for a lot of different tools.

This API key and how it relates to our Workfront connector is this is what we store in AEM during that initial connect to Workfront. So I have, let’s say this is my Workfront user that is the system admin that I’m using to connect the document custom integration with.

Once this is connected, we, AEM does not save this username or password in any way. It just uses it to fetch this API key of that system admin user. And then that is what gets stored to handle all of that, all of the access to the system actions with Workfront for that particular system admin user. So for establishing the document custom integration, for creating the document custom integration, for passing the API key back and forth. So this is that system level API key that we use to do all those actions and configuring the connector from the Workfront side. And the difference there is that this API key, let’s close this out. This API key is the API key that we need to store inside the document custom integration inside Workfront.

So this API key is visible and you’ll see it here. You can change it. The API key that we just looked at over here in the customer info, this API key gets encrypted and stored in our AEM environment and is what’s used for a lot of the different actions that take place. And if it gets reset, we just need to go in and reestablish the connection so that the new API key gets handed off. So if you’ll remember back to earlier in the call when we talked about the dispatcher configuration here for allow HTTP headers named authorization username and API key, that’s to allow that passing of the username and API key so the AEM can store that user’s API key and then encrypt it to handle a lot of that back and forth communication.

I wanted to jump over and talk about the service users. So okay, so we just talked through this step. This is the Workfront connection step.

And then we’re going to go into the system user configuration here.

So I know we’ve talked a little bit about the different system users involved. So on the AEM side, when the connector has been installed in the AEM environment, you’ll see this Workfront tools user that gets created. So this actually is an AEM service user or system user that does get created as a part of that connector install in your AEM environment. And this is a system user that we use for some of the core connection and configuration details of the connector. This is not to be confused with actions of the individual Workfront users that interact with the connector. This is specifically for system level controls and configurations.

Then once, so if you’ll see that this user has a set of permissions, so I’m going to jump over to my AEM environment and I’ll come back here to the tools menu. So Adobe Experience Manager, tools.

And then if I come over here to security in the touch UI, if I come to the permissions, I can select view all and we’re going to look for the Workfront tools user. So that user gets created automatically as a part of the install, as I mentioned, and then is given a base level of permissions required for the connector to work. So this is not something that you’ll need to have the customers do. This is nothing you’ll need to do. It will happen automatically during the install and apply these base permissions.

The one thing that is required is creating a group that then we will automatically apply each of the individual Workfront users that interact with the connector to. So I think this is called out here. You’ll see down here we have, you’ll need to create a Workfront users group in AEM manually and then assign this base level permission, slash content, slash DAM. So I’m going to jump back over to AEM and show you how that’s done here.

So again, returning to the security menu and then groups, we’d come in here and we’d create that Workfront, Workfront users group.

So once we’ve created that group, it’s as simple as that. Give the group a name. We then can come to the permission screen, search for that group.

And then as you saw here in the documentation, we need to apply a base level permission to slash content, slash DAM. And there’s one thing that I’ll call out here. This is what we include if the client wants to give their Workfront users access to everything in the AEM environment. So this is a flexible configuration. So I’m going to call that out that we have worked with many customers that say, well, I want to create very specific groups. So what we’ve done here in the security model is we have allowed the customers to have that flexibility. So we work with customers who maybe have multi-tenant Workfront environments where they’re working with external agencies and partners, and they need to be able to hide certain access from one company to another company. So what we’ve done here is we can actually be flexible in what we show to what users. So I’m creating a very generic Workfront users group. So that means what I’m doing here is that anybody that, any Workfront users that interacts with the connector will have all access to everything in the repository. And that would be applying this JCR all permission. And then hitting add. But I could create unique groups. So I could say this is Workfront North American users. This is Workfront EMEA users. And then apply the specific paths and narrow my scope of what they have access to here in this, in each of those individual groups.

And I think we’ve done this with quite a few customers, but is there any questions around how we can limit Workfront users access within the AEM environment by creating a specific custom groups like this? So you complete the action by once you’ve created this, you know, if this was for North America, for instance, then only those people in North America, you would add to that specific group. Right, exactly. Yeah. So we could, at that point, there’s some maintenance, obviously, on the AEM side, whoever the AEM group administrator is, or is responsible for the users. They could go and add each of those individual users. They could go and add each of those individual users to the appropriate group to ensure the proper access. Absolutely. So it does add an element of administration above sort of that base level access that I’m demonstrating here.

But it is possible for those customers that have the more unique needs.

And then to be clear, this, these permissions that are set here are honored during like an add new action inside of the Workfront tool. Is that correct? That’s right. Yep. If I were to go and select my document custom integration when I’m in a documents section of a project, task or issue, based on the permissions that I define here, that’s what they will have access to link and send assets.

So I’m gonna go ahead and add this group.

And then again, when the Workfront user, so now that I’ve done that step, let’s make sure I’m not missing anything here.

So what it says here is you can set this up automatically so that every user gets put in that base level group. We can set this up so there is some base level access. So there might be a folder as I work with customers there, there may be a specific directory within AEM that every users can have access to sort of that public directory. And that’s what we’d want to apply to this base Workfront users group. But then we could further permission groups and ensure that other users can’t see private folders and such.

To the point being, you have to have still that base level Workfront users group. And then you could further delineate what people are able to see based on other groups. That’s right. Yep. And then at that step though, so once we’ve done that, we’ll try to keep things simple today knowing that there is that option with each customers that want to have more specific permission set up. Um, at that point, when a user begins to interact with the tool, and when I say interact, let me describe the motion on the Workfront side with that. So I’m going to jump over, let’s keep this simple, and I’m going to start in a specific project. So let me go to my test folder.

So let’s say I’m going to create a new project from a template here. I have a base template I’m going to use and some custom form fields I’d like to fill out first. Bear with me. I’m going to, one thing I want to call out here is that I’m going to demonstrate this at a project level, but just know the documents, um, sending and linking of documents from sending documents from a Workfront environment to an AM environment, as well as linking existing assets in your AM repository to a Workfront object can be done at any object level, whether that’s a task issue or project. But what I’m just going to keep things simple today and focus on the project objects.

So when I said interacting, that means anybody who’s gone in here as a Workfront user, when they go and select the document custom integration that we’ve just set up previously, taking a minute to load, we have a lot of test environments in here.

They come and select this one. This is the one we just configured and then they’d have access to the AM environment. So this will take me to the root level of my AM environment. So if we jump over to AM, what we’re looking at here is this root level directory of all my AM folders. And then that user who just selected that document custom integration in the backend, what’s happening is that Workfront is making a call and passing that user’s information and creating a specific user to manage their permissions. So a brand new AM user gets created on the initial interaction with the Workfront connector. So one thing that we ask all of our customers to do is that they don’t have to do this every time, just once during the initial install, but the users that are interacting with the connector, that they come in here and they select add new and they select the document custom integration that they set up. And the reason we asked them to do that is that that’s the point in which that specific user’s API key again gets sent over and gets encrypted on the AM side. And then at that point we save it so that those users now can interact with the connector. So that’s a one-time thing during the initial setup that we ask their users to do is go authenticate. But then at that point they could close and use some of the more advanced features that I know we’re going to be talking about in some of the later demonstrations as well. So at this point, they should be able to come in, select the document custom integration, find any of the existing assets that may exist in the repository and link them to their Workfront project.

And now they’re linked and you’ll see that indication with the link icon here, as well as grabbing an asset, attaching it to your Workfront and sending it as well. So let me see if we can quickly grab a link to that. So again, here I’m adding a document to my Workfront project.

Again, that indication is that this asset binary actually at this point lives in the AM environment using the Webhooks API. So there is a reference and a document object that exists in my Workfront environment associated with this particular asset, but it is not duplicating the asset binary across each environment at this point. We are sending the asset binary to AM. And then this reference exists with a thumbnail image, a document object, and any metadata that we may have wanted to attach to the asset. So then we can also do the reverse. Select an asset here.

Assuming that all my document custom integrations have loaded, you’ll see the send to button. I can select that environment, and then I can also send it to the same folder here.

I may be jumping the gun, but now that we have that user from Workfront represented in AM, is that now the point where we can apply groups and security to that user? That’s right. OK. That’s right. Yep, at that point. So you’re absolutely right. When that user selected this for the first time, that’s when that user got created. That unique Workfront user gets created. And I can show you what that user looks like so you know what to look for in your AM environment. I’ve got it set up here.

So if I come to my user screen and I search for these Workfront users, this is what makes it unique. You actually have this WF dash and then their Workfront email, their Workfront username that gets applied. So then at that point, that happens automatically. It’s not that you need to go in and manually create these specific Workfront users. But this is our way of providing that flexibility again, where you can apply specific permissions for Workfront user actions. At that point, now that they’re created, we could then go and put them. As James mentioned, I’m glad you brought that up, James. We have that base level permission with that Workfront WF Workfront users group. And then we could further apply additional permissions or additional groups that have permissions and add those users to it at that point.

And these users, if there are users, this is an important one to call out as well that I’ve had conversations with customers on.

This does not mean that if you have a situation where a Workfront user also has access to an AM environment, and that’s very common, that your Workfront user may log into AM from time to time.

This is not the user login that they’ll log in with. This is merely a user that we use to manage the actions of that user between Workfront and AM. So this is not an email that should be given out after this user gets created in AM. This is not an email that should be given out to those individual users to say, hey, go log into your AM environment with this user now. They should continue using whatever login they had with that particular user.

So I do want to jump back again to this configuration dialogue to talk about one last thing before we end today’s demonstration, and that’s the event subscription service. So sort of the last item to discuss during the initial configuration steps with the customer is determine if the event subscription service is something that they plan on using.

So I would say a majority of our customers leverage the event subscription service. We maybe have one or two of them that don’t use it, but it is required for many of the advanced features like project link folders, subscribing to document or project level metadata updates.

So in order to do that, we have to hook into those events. We have to hook into the event subscription service and ensure that we create the appropriate event subscriptions or we subscribe to the appropriate events in that Workfront API. So how we do that is we’ll come over here after the configuration has been created to this event subscriptions tab. And the difference that you’ll see when you’re setting this up the first time is that this will just say enable, and you’ll have a dropdown list. And this pulls in all of the document custom integrations found within that Workfront environment. So that’s all the document custom integrations that you would see here in the document section under the custom integration. So it’s pulling in all the active ones. I should be more specific. So anything that is active will appear in this dropdown. So what we do is we want to select the integration that we’ve just set up. In this case, it was the AMAssets demo, and then we’ll enable that event subscription service. Once we’ve done that, then we’re able to set up things like the project link folders, which we’ll talk about in a future session and subscribing to document or project level updates in Workfront. So I say that this is an optional service because it really does depend on the client’s requirements. Do they want to create automatic project folders in their Workfront environment based on a change in status? So that’s how our mechanism works, and we’ll dive more into that later. But let’s say a customer has a project. We’ll go back to this project here.

And they want a linked folder to automatically get created in AM based on a change of status. So we can map it to a particular status. Let’s say when the project is set to current, it’s going to create a link folder here that then the users can come and add their assets to. But in order to do that, we have to first set up our event subscription service. And that’s really our ability on the AM side to listen for changes in the Workfront environment. So when we initially enable the event subscription service, you will not see any subscription IDs below in this table. It’ll be blank until you’ve done things like subscribe to comment syncing. So we’re listening for any updates at the project level.

Or again, another feature here is subscribe to document update events or create project link folders. So they are optional in that it really does depend on the customer’s needs if these are features that they want to leverage. But these features will not work until you’ve gone through and set up the event subscription service.

And then I’ll just call out down below. This is the other event subscriptions that belong to your Workfront environment. So if you have, it’s important to know, right, you can have multiple AM environments configured with a single Workfront instance, but not the reverse of that. So you cannot have one AM instance configured to three different Workfront environments. So it’s a one to many from Workfront to AM, but it’s not a one to many from AM to Workfront. So what this lists out is all of the other event subscriptions that have been created and belong to this particular Workfront environment, for instance.

And that’s important because the reason sometimes what will happen here, and I just want to call this out, is we’re troubleshooting with clients that sometimes you will create a document custom integration that gets deleted prior to deleting all of the event subscriptions. So then we can get some cross where there’s a new document custom integration right here, the AM assets demo that gets created. And there’s still other event subscriptions found in this table below that belong to the Workfront environment. And now there’s being some, the wires are getting crossed and the document custom integration doesn’t really know what event subscriptions to listen to. So we include this table below so that you can ensure that there’s no other AM environments. So what I’ll often do is just select my AM domain here and do a control find. And if there are any event subscriptions found in this table below, then I know there may be issues with the connector. So I’m safe in this environment. All of these events subscriptions seem to be okay. But if I were to have found this domain, the domain that I’m currently configured in, in this table, I may run into some issues with how the connector is functioning.