Hello everyone. Welcome to the Skill Exchange session on Asset Master class. Today we will

discuss on the key pillars that truly unlock the efficiency and control of your Digital Asset

Management strategy. My name is Deepak and I'm working as a Principal Engineer Software at Palo

Alto Networks. Here is a brief introduction of me. I am privileged to be part of Adobe community

from a long period of time, and I am currently an Am champion. Here is the brief agenda of what we

will cover today. We will first discuss on the power of assets in the digital landscape.

Then we will discuss into the automation core of automation that is workflows.

Then we will discuss into access and permissions. We will now connect all the dots. That is

integration strategies will be discussed. We will discuss at the end. Best practices

and key takeaways from this session. Then we will open the floor up for Q&A.

Assets are not just a simple place where you can dump your images and videos. Think of it as a

central hub. A place to manage all your digital content and a single source of truth for that

entire lifecycle of an asset right from ingestion that is, upload to approval. Reviewer, archiver

or daily churn is maintained by assets. It helps to make sure that every

team member, every campaign follows the same version of the assets, hence improving brand

consistency and reusability of the asset. It makes sure that the different

team can collaborate for assets in a single unified platform, removing that chaos and

confusion of emails and all. It improves efficiency. It makes sure that the

different renditions are compatible for web mobile leveraging multichannel

delivery. It leverages smart tags via intelligent tagging as well as provides

full text and metadata search. It makes sure that the millions of

assets are being placed at one place, and they are rendered to the user in real time, removing

any performance lag. Now we will discuss the workflows. Workflows

are the core of automation. So what are them? They are automated sequence of steps to process and

manage assets. Why workflows are so important for assets. They help to automate repetitive tasks, for

example, sending notifications, generating render renditions, or extracting metadata. They

enforce business rules, so all the complaints will be followed by using workflows.

Since all the assets follow a particular predefined path, it helps to enhance the quality

of the assets and consistency is maintained. The time to market for the campaigns

is reduced using this automation, which is a real world requirement. All the manual efforts

are reduced and it frees up the time for providing and maintaining strategy by our team

members. Now in this slide, we will discuss on an example scenario where a new marketing image is

being created. The designer uploads that initial draft to a particular folder which is being

reviewed by marketing manager once he gets the notification of that. Once the feedback is left,

the designer make changes appropriately and it's routed to a concerned person like a brand

director. Once it is approved, the asset is automatically uploaded or moved to a different

folder. Done with the different steps as per the business requirement, and then it can be published

downstream to website or different social channels. And once the campaign is finished, the

asset can be deleted or moved to an archive folder. There are some

out-of-the-box workflows in damn I want to cover. I will start with the most important and

fundamental one. Dam update asset workflow. This is triggered whenever the asset is uploaded or

updated. Some of the key steps with this workflow are rendition generation or different touchpoints

like web mobile. Metadata extraction. Processing. Smart tags. It basically makes your assets

ready for a multi-channel uses. One difference in cloud service is heavy lifting for asset

processing. That is, metadata extraction and rendition generation are offloaded to asset

compute microservice. This helps for performance scalability. Now Dam Update asset is

a transient workflow for clouds where its instance is not persisted in the JCR

repository, hence providing for a superior scalability. Here is the flow in the cloud service.

Whenever an asset is uploaded, the binary is uploaded to the cloud storage and all the

requests like metadata extraction and rendition generation are taken care by asset compute

microservices and once it is done, Am is notified and Am updates the reference with the new

renditions. Some other workflows I want to discuss one is Dam metadata right back.

It makes sure that the consistency is achieved between the asset metadata and the original file.

Any changes in the metadata. This workflow writes back to the binary file. Dynamic media

process. Asset workflow is very powerful one it helps to handle different image sets like your

spin images, 360 images, flipped images, and helps for video encoding. Whenever the video is uploaded

in different bitrates and resolution, it is encoded and served to the user, reducing the

lagging. And all other important workflow I want to discuss is request for activation, so it takes

care of two steps. One is concerned the group is sent for review, and once it is reviewed, then it

is published to life. These out-of-the-box workflows are very robust foundation, but in most

of the cases we should extend them or optimize as per the business needs for customizing workflows,

workflow console is very important. It can be found under tools. You go to workflows and then

you can create your models. So here you can customize it using out-of-the-box component and

multiple components provided by assets. Some core workflow components I want to discuss. One this

process steps, all the Java code can be implemented using Workflow Process Interface

or Figma scripts to handle complex logics. For example, doing an integration with external system

we can achieve using this process step. Next is the participant step. If there is a some

task for review, it is assigned to a specific users or groups. With this participant step and

post approval only, it will go to the next step. Other important step is dynamic participant step.

Here, the group to which the task is to be assigned is computed at runtime. For example, if an

asset is belonging to a German domain, then it will be assigned to a German manager group and

if asset is belonging to the English or US site, then it will be assigned to the US manager.

Or an end splits are very helpful or is used for conditional branching. For example, an asset is

sent for approval, then either it will be published or it will be sent back for the changes

and split is helpful for parallel processing, for example, for an asset to be published to life. We

should make sure that the SEO that is the metadata is proper and the content and imagery is

proper. Post. Both steps are taken care. Then only it will go to the next step with an split.

Other important step I want to mention is the container step for example of a workflow is very

complex, so group of related steps can be moved to a different workflow and that workflow can be

used as a container step. This helps to clean up our already complex workflow. There are a lot of

real world customization examples. Some of the important examples I have mentioned here like

applying dynamic watermarking. Integrating notifications with Slack or Teams whenever it is

sent for renewal steps and we can push the metadata into different downstream like PIM and

others. I also want to discuss some of the advanced workflows which are event

driven. Whenever there are changes in JCR properties, for example, a node is created or a

node is updated, or an asset is moved to a different folder or an replication event is

triggered. Workflow launches can be initiated. Workflow launches will internally call the model,

and it can take care of the proper steps. And for more advanced steps, we can use a custom event

listeners and invoke them programmatically using the workflow API. So I have also shared the

screenshots of the different types how it is there. The path is basically a payload and asset

path where the launcher is triggered based on the events like created, deleted, replicated, or moved

to a different folder. Now I also want to discuss on some of the best practices of

workflow we should follow. One is we should always optimize the performance. The workflow is a

sequence of large number of steps, and some steps can take a longer time. Hence, we should use the

async execution so that that long thread can be running separately and it avoids to block the

workflow engine. Since CPU and memory is very important, we should make sure that our Java code

is very lightweight and we should not traverse the whole node to find the asset. We should use

psql or Query builder for traversals. We should make sure that only needful renditions are being

processed to optimize the asset processing. We should make sure that our workflow models are

versioned. For example, the workflow model path might be either conf or wear, and we should push

it to git so that it can be tracked and people can make the changes appropriately and know the

history when it was updated or modified. We should always make sure we are resilient with error

handling. Sometimes external systems may be down, so we should always implement a retrial logic. We

should make sure that our logs are very robust so it can be easily debugged by the team. We always

should have a fallback mechanisms in place so that any failures can be handled at our end. And

at the last we should use workflow exception. So we know that this workflow is a failure and a

notification can be sent to a group, or a logic can be updated as per the need.

Now we will be discussing on one of the important aspects of governance how to control the access,

which is the foundation for asset security where permissions are so much important for Dam. First,

it makes sure that our assets are safeguarded and only confidential assets can be accessed

by appropriate users and groups. It makes sure that the approved assets are being

published. So for example, if a logo is outdated. It will not be published because it will not be

accessible. It will help to enforce regulatory compliance with different rules like GDPR and

other privacy laws. It makes sure that unauthorized deletions and changes are not being

done since a proper users have proper permissions. What is the

permission framework behind it? It is based on your jackrabbit Access control list mechanism,

which offers granular control, but we should have a great understanding of the same. It is managed

through users, groups and privileges, which we will be discussing in the next slide. So now

we will discuss on what are the key or the building blocks of our asset security. First is

users and groups. Users are very simple. The individual accounts that log into our Am asset

instance are named as users. What are groups? Groups a collection of the users. They can be

either system groups or they can be custom groups as per our need and department, and we

should always take a note to always assign the permissions to groups, not individuals. So if some

new user has come, we can remove it from the group and add accordingly if the new user comes.

So what are privileges? Privileges are basically permissions assigned to those users and groups.

What they can do so they can read, write, add the child nodes, remove nodes, manage the versions,

replicate. So these are some of the privileges for users and groups. Now most important are

access control lists are the permissions which are provided. So what are they. They are rules

which are specified to a specific path. So that path can be either a folder or an asset itself.

Internally they contains asset control entities which allows like grant or deny

privileges to users or groups like what they can access, read or write is decided

by AC ACS, that is, access control entities which are part of our ACLs. A few points to note

that permissions are always inherited down the content tree, and denial rule takes precedence

over the allow rule, which we'll discuss in the further slides. Here is the UI

for permissions I wanted to explain. So for the group dam users you will see ACS listed

here. And on the right side you can like add a new path and they provide the privileges like JCR,

read, etc. and the type is also whether it's allow or deny. So how we

can access it, we can go to tools, security, users and group. There we can create a custom groups or

update the ACS for the current groups for the asset folder levels. Setting permissions is very

important and how we can achieve is listed here. So we should go to that particular folder. Then we

should go to the properties tab. And from properties we should open the permissions tab as

we can see in the right hand side screenshot. There we can add a user or a group and the roles

we can add it whether it's an owner, editor or a viewer. So this helps to manage our assets. And as

we discuss that the permissions are inherited down the content tree. So for a parent folder

permissions will be inherited by all the child folders and assets. The permission evaluation

logic works like deny always takes precedence over allow. More specific paths will always take

precedence over the general paths. For example, if the parent folder is slash content, slash them,

then a child path like slash content slash slash a dot jpg will take a precedence over the parent

and its permissions will be used. We should always consider the orders of access control

entities in our permission design, so we should make sure that our orders are proper in there

since first match wins for the same set of permissions. Now we will discuss on some of the

core principles for the permission. First important is principle of least privileges. If a

user needs read, just give him the read permission. Don't give him the right permission. We should

always have the group based permission. So it's very easy and if someone is new,

then we can add him to the group and if someone we want to remove, we can easily remove. So it's

very simplification of our audit process and we should always keep this permission simple. You

should not make it complex, since by default all the users and groups have a denied permission by

assets, so we should selectively give them an allow based permission one we should use deny

only when it's sparingly urgent, and we want to provide a very specific group

or a user a deny permission, then only use deny. As always, use allow. From

an operational point of view, there are some best practices which we should be taking a note of. We

should make sure that our permissions are audited regularly, so any permissions which we are not

needing, we can remove it. We should make sure that all our environments have the same permissions, so

that it can be properly tested, and issues are not carried forward to the higher environments. We

should document our permissions. So it's very helpful for the team and new. Our team members can

also easily understand. We should always make sure that our permissions are replicated to the

publisher, since they will be serving the content downstream to different platform like websites or

social. Since we have discussed on the workflows and permissions, now comes the

integration which is the most important point. So think of your assets as a central hub.

It's not a silo, it's a connector. And it should be integrated with different marketing and

technological stack. Why integration is so much a needful one is all the assets

are aligned across all the systems in real time, which helps for a consistent brand experience

since the same visuals are delivered to each and every channel. Content delivery is very fast. With

this, we can make sure that our already great metadata are enriched by integration with

different systems like PIM, CRM or AI services. It also ensures that workflows are optimized for

other systems, also like CMS and PIM or other e-commerce platforms.

So integration is possible with large number of the systems. In this slide, I mentioned some of the

important systems which we are using in our projects. Like PIM, we can integrate to sync the

product images descriptions. We can use a CRM for personalized asset delivery. We can use an ERP

for enriching the assets with business data. We can use a marketing automation platform

integration for Marketo to feed campaign ready assets directly. We can now integrate with

CDP to provide the customized assets based on the user past history. We

can integrate with CDM to deliver the assets in very fast manner. We can integrate with Creative

Cloud like Photoshop's and others. There are some integration patterns for assets. I will be

discussing on the three four important ones which we are using. First is M as the master dam. So

Am is a single source of truth and authoritative source for all your contents. All the assets flow

from Am to the downstream like web social. So this is happening for all the new projects as well as

for the large enterprises. Where Am is the primary content hub? There are some legacy projects, like

very old projects which were not earlier in Am that can be having M as a consumer or a slave dam.

So where assets are present in that system like a legacy dam, and they are slowly ingested into

Am and that Am acids are served downstream to the website and other socials. So slowly they are

moving from the external systems to am. Other important model which is used in most

of the projects is the hybrid model, where some of the assets are managed by Am and some are managed

by the external systems, and one is optimization. Why CDM is very

helpful. So can if it is dynamic media already a dynamic media takes care for rendering those

assets. Else we can use the CDM like Akamai or Cloudflare to make sure that the assets are

served to the users in very fast speed. For example, if a user from India requests the assets

and the server is in US, then an ad server near India should serve that content. Now I want

to discuss on some of the use cases for integration. After discussing all the integration

pattern. One is we can sing the content from the platforms to. Am for example

PIM we can use the product images, SKU details and user workflow internally by process step

so that Am assets are linked to that PIM metadata. We

can make sure that Am assets are served to different platforms like Marketo or Social, so all

the approved assets can be served for marketing campaigns. We should have a

integration with Dynamic Media and CDN, as I have mentioned previously.

And although also we should have a integration currently with most of the tools like Photoshop,

illustrator, where the photographer can directly make the updates to Am,

and then they can integrate and leverage those after checking in the Photoshop.

Now discussing on the integration. There are some of the governance which we should learn, take and

incorporate into our asset projects. We should regularly do troubleshooting

and do an operational visibility. We should see like which workflows are active, which are

completed. We should regularly monitor the logs. We should always monitor the queue health. We should

see which workflows are stuck which are slow so we can optimize and make them better. We should

use a SKL to end query builder queries instead of traversals, and we should use the slink console to

do the diagnostics. We should make sure that the proper lifecycle of an asset is being implemented

at our end, using any needful workflow and process. We should make sure that the folder follows a

proper regular convention and the asset usage is being reviewed. So if an asset is redundant, we

should get rid of it. We should always make sure that performance tuning is done by using Lucene

or queries wherever we have to faster asset search or infrastructure. CPU memory should be

always advanced, and we should always leverage dispatcher and CDN for delivery in very high

speed. Now I want to mention some of the key takeaways from the session. One is

workflows which are a source of automation are very powerful and we should leverage them into

our asset projects. We should make sure that the proper governance is taken care

with applying proper permissions. We should make sure that integration is there for

assets to all available digital ecosystem to enhance the maximum potential of assets.

We should make sure that we always do a regular monitoring, regular troubleshooting, and we

optimize our current Am assets implementation so that it is more efficient and performant in

future. We should always establish the clear policies for asset

management and security, since governance helps and is very useful. Now we will open

the floor for Q&A.

Thank you so much, Deepak for that presentation. I love how you made some complex and technical

topic topics feel so manageable. Thanks for having me in this session. It was very nice. I'm

thankful to you, Adobe and my team at Palo Alto Networks for encouraging me and having in this

collection session. At any time, of course, so that we know the drill. Let's take some questions. Make

sure to drop yours in the chat if you haven't already. So we're going to get started with a

question from Leanne. And she's asking how does the workflow notification come through to the

approver. Is that coming through via email or some other channel? Uh, sure. So once we

configure a participant step, uh, we assign a user or a group, uh, where the notification should come.

So normally, uh, it goes to the inbox, they will receive the mail notification. So in M console

they can go to the inbox and check. Getting email is also a good practice. So for this we separately

need to configure a mail service basic mail service and make sure that our email

notifications are in place. So that email goes to the proper concerned users or groups and they can

take the action. But if it is not configured, it will by default go to m, uh inbox. They can go to

the bell notifications and see them and they can uh, take an action. If it is fine them, they can

approve and it will go to the next step or and as per the configuration appropriately then. Gotcha.

Okay. Thank you. Next up we have a question from someone using Am assets on prem 6.5.

Um and this person is asking what can be done when assets get stuck in a workflow. They're not

sure why that occurs. And is it possible to set up or track a clear failed status? And for

more context, their use case is multiple uploads share the same sh one hash. They're not

duplicates, but they end up failed sometimes. Anything you can share on that note? Yeah, that's a

nice question. And it can happen sometimes. Um, so sometimes our workflow, um,

assets can get stuck. So the recommended um steps will be which will go to the workflow instance

console, which will check for the workflows which are in your running or suspended state.

And uh we should click on them. We we will check the history like the logs where they are

feeling. So either we should terminate or suspend them. And uh, if we see the proper

reasoning, we get why it's failed. Then we can reprocess the workflow. We can again run the

workflow on that asset and it should be fine. We can like trace our logs. And if we are

constantly seeing that it's failing. So it might be a code issue that it's a permission level

issue or some repository access issue. So that should be rectified. And depending upon the use

case you mentioned so you can share. We can discuss more on this in detail during our skill

post office hours. But yeah, it should be for sure related to some functionality at the end and can

be debugged and fixed and to and for the initial question mention, you can go to the workflow

instance console, check for all the workflows in the running and suspended state, and take a look

at your logs and the appropriate actions. Perfect. Thank you. Yeah, that series of steps you

detailed for troubleshooting is super helpful. So I appreciate that. And also great shout out

if there's anything, um, extra technical requires more nuance or context. These those follow up

sessions in September that we've been dropping links for throughout the day is a great time. Um,

to dig deeper into some of those questions from this session. So that's a great call out to Deepak.

Yeah. Um, another question about, is it a best practice to maintain all permissions as code

artifacts in OCI config file? That's a great question. In the

previous versions of Am, we were handling permissions with your package manager. With the

newer versions of M on prem and cloud, it is recommended for a best practice to do it

with your repository repo unit script. So that is recommended and the best practice as compared to

the OCI configuration mentioned. So and this repo init script will help in one other way that it

will be the same across your environment, so you can deploy the same in your lower environments

like int or in the higher environments like, uh, author and production. Like in the past, we used

to also handle with the package manager. That is also fine, but since it's a repository level

config and more granular, so it's better in a recommended way to have the basic, um, permissions

within your appointed script. Gotcha, gotcha. Thank you.

Um, few more questions coming in. Michael is wondering if you have anything you can share

around how you're tuning your queries. Sure. That's a nice

question. So we should make sure that we have properly added, uh, indexes to make sure

that our queries are fine tuned and we don't traverse the whole, uh, demo assets, for example,

whenever we are implementing a custom Java code using a process. Whether it's a process step or

your participant step, make sure that the query is fine tuned, like whether it's a query builder or

your sequel to. We should use it efficiently. For example, we should not traverse through all the

assets. We should just, uh, traverse the needful nodes. And we should also make sure that the

indexes are added so that the results and retrieval are faster. But yeah, it's very important

to make sure we use the proper queries, whether it's equal to a query builder. And we should just

target tool to the appropriate asset. So in AMM workflow there is a one good leverage. You have a

workflow payload. So you should just play around it rather than traversing the whole repository

or assets because the payload will give you an appropriate path. For example, if you are

triggering it on an asset A, so you will get the asset a path in the payload and in the back end

you can do computation accordingly rather than traversing through old repository. And just make

sure that proper indexes are at. Yeah, that's a nice question. Gotcha, gotcha. Thank you.

Um, another great question here from Eric. Um, Deepak, how do you modify, uh, rendition pixel sizes

on cloud, if you're familiar with that? Um, and as a follow up to that, if there are multiple

renditions, is it possible select just one type of those renditions to download or does it need. Um,

or does one need to download the full rendition pack for multiple rendition sizes? Sure. So like, uh,

on cloud have not worked like much like we have explored mainly via sandbox currently. Uh, I'm

using, uh, on prem, but I've explored like cloud sandbox and, uh, know the differences between cloud

and on prem, like how we are handling. So this is one good like in our workflow models, we have a

step so we can define the renditions there itself. For example, if you are using the customized, uh,

data set workflow or an out of the box workflow which you are going to extend and customize so

that you can configure the renditions which step you want. So if you already have a dynamic media

you can configure in the dynamic media step the renditions, or if you just want in the thumbnail

rendition something so you can update in that step whatever the rendition size you want. And if

you want to rerun it after updating or your workflow model, then you can just reprocess your

assets with that and it will take care. And if you are working on prem and you don't have in on prem,

we basically are used or seen seven for dynamic media assets. So if you have seen seven

configuration set, so whatever the dynamic renditions you are doing, the M will basically

push those assets after applying the workflow to scene seven. So in that way, the whatever we

configure in that workflow model, step renditions for the dynamic media, it will take into place. So

it's possible and I can in my post office hours also show you the configuration and detailed

steps how we do atm. So yeah, I love that use case. That sounds great.

I'm seeing another question that I really like from Priya, who's asking about the right way to

set up groups in assets. So she's asking, um, for creating groups. Is it creating them directly in

Adobe IMS, or should she be leveraging, uh, Active Directory, creating them in Active Directory? Uh,

and then it gets synced to IMS and AUM. Yeah, I think that's a great

question. And how it's being evolving from the versions of I am on the past versions like on

Am on prem. Basically we used to set in the console itself, you know, so we created the new

groups and exported with Package Manager and with the newer versions of M on prem and

cloud. Uh, as I mentioned, like initial um permissions we are handling with repo in it. So

you give you we can configure using that IMS and it can sink to a cloud. So that is

also being one of the way. Or if you are someone admin level access who is drawing on cloud so he

can manage. So yeah, I think both these things are feasible that I have also heard a lot of things

that, uh, you use IMS and it is getting synced those groups to your cloud. So yeah, that is also

fine way. And as I mentioned, the if some super admin is doing that is helpful and we should make

sure that our init script are properly configured and pushed to the code base. So that's a

fine, fine question. And I can, I think, cover more about it in a post. Uh, champion officers

also like a detailed use case for this. Awesome. Yeah, I love that. Um, another

great question from Rajesh here. He's wondering how he can better troubleshoot asset ingestion

issues. Um, so in your session, Deepak, you mentioned asset compute service used in in CS to

process asset renditions. So what's the way one. What's your advice for troubleshooting asset

ingestion issues? And then how are you monitoring that over time? Uh, sure.

So to it also it depends on how we are doing asset ingestion. Like in traditional way we can, uh,

bulk select the assets and upload them to a particular folder. And with the advancement of

higher m version. So and cloud we are doing it via Azure. Also we can have the assets in Azure and

we can do ingestion into Am. So one thing I will always recommend it do asset

ingestion in batches not do in bulk like um and also monitor like for example if there are

some things uh, which is not needed in your business context, for example, you don't need uh

metadata right back functionality, you don't need a large number of metadata or renditions for your

business use case. You just extend the workflow and omit those steps. So if your business use case

says that you don't need so it's better and advisable, and then you can do your ingestion in

batches. Not all the assets at work, whether you do directly upload or you do it via Azure and then

importing to or am. So I think it's done and it's very doable. I think most

of the organizations are doing it, so asset ingestion in batches is fine and should not be a

issue. We should monitor. And we should also make sure what our business priorities are. As I

mentioned that unnecessarily steps we should omit. Yep. Gotcha. And following up, speaking

of workflows, a follow up question to that specifically in managed services, if you're

familiar, but Priya's asking, is it possible to offload workflow processing to a different server

in managed services? Yeah, so it will be done, I think

with customization only, for example, in cloud I mentioned that you can do to asset compute

microservice in ACM on prem. Also I think we can if we have some custom logic, we can do it like

what we can do, we can override or extend or out of the box workflow, handle all the logic by

ourselves like in the back end, and do it like how we want to do as per. We can also think to

integrate with the APIs and check with our Adobe wrap. Like for example, if a compute microservice

can be given it as a package, or how we can leverage that. But yeah, it's a good use case. How

we can do in prem to improve the performance of the workflows. Yeah that's a nice perspective.

Excellent. And I think we'll have time for maybe 1 or 2 more. Um, but I'm curious Deepak specifically

in in work throws. Is there anything any best practice you can share about optimizing workflows

out of the box? Yeah, I think some steps I covered in the

questions. Like, we should understand our business need. For example, if we don't need extra

renditions or metadata right back, we should omit our steps. If we don't have seen

seven, for example, then we should just remove that thing instead of it throwing the error. And same

with the smart text. Like if we need the smart text, then we should configure that model and use.

And if we don't need, we should just remove it. So one thing will be like always optimize your

workflow, whatever is per business need and context. And most probably I will try to leverage

like clone extend out of the box workflow and use it. Second should be like I will make sure of my

launchers. I will track my launchers that sometimes on any JCR event like modification and

all my out-of-the-box workflow launchers can get triggered. So that creates a chaos and unnecessary

processing. So I should monitor my launchers, just have the needful ones and see like which

workflows it is triggering. Thirdly, I will make sure that my workflow code is committed to the

code base so that the changes are not lost when moving from a lower environment to a higher

environment. With m higher versions, we have the config available in conf, so that can be pushed to

the higher environments. And fourthly, as I mentioned, like we should have a proper governance

and follow a proper logging practice like code practices should be there. Proper lag logging,

retry mechanism should be there so that our workflows are more robust and possible. Workflows

are super important for automation, and we should leverage it in a good way. And we should always

see our business use case. So yeah I think it's very powerful future. Amazing. And that's perfect

timing. Deepak, thank you so much for joining us and for sharing your efforts with all of us today.

Yeah, thanks a lot for having me. Thanks to the entire Adobe team and Palo Alto Networks team for

supporting me. Thank you all. Bye.