hello hello and welcome everybody uh welcome to this 44th already uh platform Academy session once more I am joined by my friend Andrew Barnes I'm very grateful that he's here and talking through this awesome topic with us uh today uh this will be a little tougher nut than usual a little more technical than usual uh but I really hope this topic will help you all understand how you can uh secure your workflow automation products and this is a live webinar we have a presentation of course but today we also get some nice uh little demos presented by my friend Andrew please give a quick intruction to yourself oh thank you so much for having me 44 that's amazing uh remember your first one thank you so much for having me today I'm Andrew Barnes I'm a product success director so I work in a post sales capacity here at service now been doing service now stuff for a little over 10 years at service now itself for five years and I just love joining these sessions and so I love to hear from you today in the chat and ask questions in the question answer awesome thank you so much five years is where I almost am at at service now so hi everyone my name is Lisa I live in Germany I've been with service now for almost 5 years I'll have my anniversary in February I've been working in the service now space for over seven almost eight years now uh I started in the Helsinki time frame roundabout so I'm curious to know when all of you started and when you first uh had some contact with flow designer so put that in chat please I live in Germany as I said I uh am responsible on the platform outbound uh product management uh Team for the workf automation tools and that is flow designer decision Builder and process automation designer which coincidentally are the products we're talking about today I will go through some housekeeping slides you know this one uh our safe Harvest statement just in case that we're talking about any futur looking uh things uh please don't make any purchasing decisions based on what we say today this Academy is part of a larger Set ofies uh that are run by my colleagues in the platform upbound uh Team we have academies about next experience about mobile about virtual agent about our very hot topic AI including geni of course analytics and way more and then uh I think we'll get into some details about today's session so first of all um I'll do a very very quick intro of workflow automation was it what is it what products are included and what do they do what are they good for uh then our first part will be application access so where can you develop your workflows second is designer access which tools can you use to create your workflows and how much uh can you do with them and then third execution access so when your workflows are created and published and deployed to your prod instance what happens when you use them how do you determine what can be read written updated or deleted with those workflows and to give you a quick high level overview of the products we're uh looking at today um mentioned before we have a flow designer flow designer was started as a uh business rule replacement engine Way Way Back in Kingston or even Jakarta uh but by now it is so much more and it is 100% or even 120 and more perc replacement for workflow automation uh after iing business rules scheduled jobs inbound email actions inbound rest all kinds of things so if you haven't all kinds of things all kinds of things if you are interested all of the stuff that is possible with flow designer I encourage you to take a look at the center of excellence articles and most specifically uh the migration session that we did for flow designer in the past basically flow designer is the heart uh workflow engine at the heart of service now and it drives all all automation on the now platform form second process automation designer which is a kind of extension to flow designer because process automation designer every individual activity runs on a flow subflow or flow action so the good part is you can reuse what you already created in flow designer to build out your complex cross Enterprise uh processes with process automation designer the awesome part about pad for short is that it also provides you your agents your process workers with an intuitive UI so that they can get guided through their processes and know what is the next step where in the process are they which information is required to drive the process forward and then third my favorite product in these and I do love all three but it is my favorite is decision Builder and decision Builder is an amazing way to uh decouple your Lo your decisions your logic your conditions from your flows which is very amazing because it saves you complex if then else uh uh constructs it makes your flows so much easier to read and moreover you can hand over ownership of decisions how much um discount you want to give uh what is the right group to handle a task what is the right uh text that you want to send out in notification so all of these smaller decisions but also bigger decisions can be made in decision Builder call from flow designer call from script and so on so definitely look at decision Builder it's really cool I love it and with that what are what are we doing today basically when we're talking about flow designer padn uh also decisions there are multiple levels of Access Control that we have in our platform that you can use to determine where you can build your processes and flows that is the application access so which apps can you build them in or can you build them everywhere if you're an admin second of all what can you do with your designer do you even have access to everything in the designer maybe somebody's only allowed to create subflows but not actions maybe somebody can only use uh some parts of decision Builder we'll find out more about that in the second CH part of this and then the third layer is execution access so once you have your logic deployed what happens then what kinds of Records can you access what can you update what can you do with your logic and that'll be explored in the execution access part now I give give it up to Andrew Thank you Lisa so yeah I'm gonna talk about that that bottom layer first um so we're going to talk about how you gain access to these tools um in the platform and how you can get granular access so we're going to talk about delegated development today so delegated development is an ability for you to Grant users in groups uh granular access on a scope by scope basis to different parts of the application building uh Arena so we don't want to give everyone admin um and we may not even want to give the same user the same access in all applications so across different Scopes they may need different levels of access and delegated development is the capability in the platform that allows us to unlock that that uh ability so the kinds of things that you'll find in delegated uh development is uh you know whether or not you can access all metadata types or specific ones like Integrations UI Builder low design er um security so whether or not you can manage ACLS um then you know some higher stuff of like can you publish this application can you control um the ability to connect to Source control can you delete the application so is a very uh as you can see with all the toggles here on the screen uh it's a very granular way on a scope by scope basis to Grant access to users and groups um to that scope to those capabilities in that scope now not everyone is going to see delegated development the same way in your instances and why is that the answer is so you might see it this way yeah you might see it this way when you go to Dev studio and you go manage developers but if you go to Dev studio and you don't see manag developers you'll see and uh manage collaborators and that will mean that you have app engine Studio installed and with app engine studio uh since that tool was designed to scale out the number of distributed developers um we we realized we needed to create some groupings of those permissions to make it easier to Grant those to more folks faster across more Scopes uh and so we created uh what are called collaboration descriptors um and and those are groupings of those delegated Dev permissions that you can then Grant out as a group um so if you have uh the manag developers you don't have app engine Studio but if you have app engine Studio you'll have this um application collaboration which contains those collaboration descriptors um and that is also part of the management uh process there in app Studio we won't go into detail um but it allows you to do things like approve granting those uh rights to folks and using things like decision tables and flows to automate the decisions uh and know which ones need actually uh approvals or which ones get Auto approved um so with that um we're actually going to uh quickly do a real poll while I get set up to do a demo to show you what this looks like nice so we have a quick poll it's just one question and we want to know if you are using any form of delegated development already and that is a large number that says no so now that you learn about it today I hope you will be considering it together with the 20% who are considering it awesome so while you're answering that poll I'll go ahead and get started and show you what the app collaboration descriptors look like in an instance so I have three here um which are groupings of it but I'm going to actually create a new one real quick so we're gonna give it a name for Lisa yay um and and then once we save it we're gonna be able to choose those delegated Dev permissions that we're going to group together in this uh descriptor now I'm going to hit edit and this is going to um these all of these uh in this little collection uh box are the toggles from that other screen so I can choose that Lisa can can use Source control um she could could publish to the app repo and use flow designer we've got to give her decision tables because it's her favorite yes uh and notifications and process automation designer so this collection of permissions will now be able to be granted to multiple users across multiple Scopes uh much more uh efficiently uh using these collaboration descriptors um and the way that that's leveraged is in something like app engine Studio or developer studio um so in app engine Studio when I'm on a app I click this little collaborate with others and we're gonna pick a let's see let's be Bob Bob can oh I have to refresh it but what you can see is the descriptor will be available here the Lisa one would be available here um I don't want to take the time to refresh the screen um but we would choose the the for Lisa one and hit send and then depending on the automation that I've got set up in app engine management Center um it will go to an approver so it'll create a collaboration task and there will be an approval and then the right people will approve that uh and then the role will be granted to those users uh in this case Bob and then Bob would be able to use those permissions that they've just been granted all right so our results for our poll were what is that 12% delegated Dev 15% considering it and 68% uh not doing any delegated Deb right now awesome thanks everyone thank you so much this uh next part is uh now about the designer access so we want to understand and after we have chosen the uh SC Scopes the app Scopes that people can work on and create their artifacts in uh now we want to determine what kind of permissions you have to work with each of the designers that we do have that is flow designer process automation designer and decision builder for flow designer we have a couple of roles in our system and I will also uh post a link for an article later that had has all of the links all of the resources you don't have to remember these uh I will post that later and you can look all of that up uh but basically flow designer has uh three different levels of flow uh of roles uh one that allows you to create and modify either flows or actions so if you have the flow designer role you can create flows and subflows if you have the action designer role you can create actions uh interestingly enough in this place is that the action designer is not included in flow designer so that has to be granted individually next in uh one of the recent releases I believe that was uh Tokyo or Utah we added read only rool to a flow designer so sometimes you have some business owners uh business process owners uh that do want to look at the flows uh how they're being built out uh and you can grant permissions to those folks to uh look up how they're configured uh to understand what's happening but then also to look at operations which are the execution details of uh any of those artifacts and then third level are reporting roles that allow you to look at at dashboards like the fdh dashboard to understand flow usage flow executions and to help debugging or understand if there uh when there are a lot of uh flows that might be stuck and you want to uh get into the details of that the next uh slide I believe is process automation designer which has um a little different setup of roles uh but the idea is basically the same uh you're either uh full process admin uh and included in the Pro full process admin role you can have uh permissions to be a Content author uh this allows you to create uh activity definitions you can be a trigger author this allows you to uh create trigger definitions and you can be a process author which allows you to assemble triggers and activities into a process and each three all three of these are included in the full process admin next there's also a reporting assess because that totally makes sense to have uh maybe someone uh take a look look again at process executions find out which ones are executed most uh which ones maybe take long because they get stuck at some point because some action is not being completed this helps you understand how you can improve your processes and then lastly there's a r a number of shared roles that are needed for uh for a Playbook experience configuration so being able to view or edit experience activity types and properties um that might be useful too and because you can also create your own uh activity uis I think those roles are involved in that as well and then third uh this is a this is really a presentation of Threes which is very very neat I like threes and decision Builder roles we have three products we have three layers this is amazing uh in decision ision Builder uh roles are uh set up to be uh depending on what people can do in decision Builder uh first of all again a kind of readon role so the decision table reader is allowed to look at decisions they can view the inputs they can view the rows and conditions but they cannot make any changes except for they can export to and edit in Excel this is a good role to assign to uh very low code or no code business process owners and decision owners to let them actually do decisions or update decisions uh decision details without changing anything about the architecture of the decision table uh the decision result editor is allowed to only edit the result columns uh column entries but not the definition of the result columns the rule author is allowed to to do everything above and edit the whole row including the conditions and the result entries but not the configuration and the layout of the columns and then lastly we have the decision table admin or if you're just a regular admin you can edit everything in the decision table including inputs including deciding what uh condition columns do we have which result columns do we have and then uh I think Andrew also has a small demo prepared for this part I do thank you Lisa so I am now in a in the same instance but as a different user so this user that I'm at is shockingly called decision reader and so we're going to go ahead can they do so this user has the decision reader permissions and so this is mostly a readon role um but they do have the ability so I have this uh decision uh open here and so I can see the inputs I can see the conditions I can see the results um and I can export them so I've got the little export button but I can't make any edits so I can't change any of these um the the choices for the results I can't change the conditions um but I can see them so this you can test I just noticed you can test which is awesome which is also a new feature by the way is a new feature we also snuck in drafting there uh today um I'm going to quickly impersonate another user which is going to be a shockingly similar name so we're going to do decision Emoji decision uh editor so we're going to use that intermediate user and we're g to quickly switch over to that user we're going to reload our decision table here in the decision Builder interface and we'll see now that this user what what what were they supposed to be able to do let's go quickly look at our our cheat sheet so that is a very similar to the table reader but we should be able to now edit result column values so so can we edit result column values we have to create a draft to create draft I just updated this version now that we have drafts and now you have to do drafts yes you can do drafts now I can change the value of the results here nice and now I can save that and then I could publish it perfect and this gives me a warning are you sure that and then now in our our theme of Threes we're going to impersonate the author and then we'll quickly reload the decision Builder interpas yes and we're going to reference our handy list here what should the author be able to do in addition to the other things is they should be able to rearrange the table rows and edit the conditions all right right let's see if they can do so we create a draft and now we should be able to get a new add a row here which we can do yay and is and we'll choose oh 10 people now for the number of people uh and we cars for 10 people oh let's go with four cars for 10 people I don't think two will cut it and then we would save and publish that so that is uh you know very quickly what it looks like when the users with different roles are able to interact with decision Builder so we got rolls out of our way and now we come to the more complicated things and that is access to individual things in your interface and that will be uh over to you Andrew oh I was coming this yes I was look at that hey it's back to me I handed it off to myself thanks Andrew so feature access absolutely so uh similarly uh where we were talking about the different roles that you can grant for a decision Builder we have some very granular permissions able to be done in flow author so we can assign those roles to you know these individual features to uh unlock those capabilities at a very granular way so uh Lisa put in this handy note there um so if you turn this on this is not turned on by default so if you turn this on uh you need to make sure that you don't remove permissions uh that that otherwise were already being granted to users unless you mean to uh so you need to go add in things like flow designer flowcore designer and action designer to the appropriate areas uh in the flow authoring features so that you make sure that you're granting the right amount of access uh to each of these uh that you want so what are some of these flow authoring features so we've got things like testing being able to copy a flow so there may be times where you have users that you don't want to be able to copy flows um you know whether or not they can create a code snippet so there's certainly users uh that that just don't need to be able to do that and so I can just hide that from the interface from them and and they don't uh they don't need it and they don't even need to know about it so uh the ability to narrow down uh what's available uh in flow designer this way is very handy feature to help make sure that the right users have the right access and and don't get overwhelmed with options that they really shouldn't even uh need uh so you can you can hide them from them which is pretty great yeah I think this is very neat feature it's it's uh it's hidden it's very kind unique in the surface now space as well though but it is very awesome it is and uh paired with that in a very similar concept it's content filtering so the on the previous one we're talking about the features so the different things in the interface like you know the activation or testing of the flows um we also can narrow down the content that they can inter interact with inflows and so why might I want to do that so there's a lot of cases and where I would like to be able to control who has access to things like Spokes and particular actions in spokes so I have some very powerful things in a tool like service now like lots of companies have things like active directory integration setup and you can use the active directory actions uh to add users and delete users from your active directory uh you know and there are definitely users that I don't want to be able to have that capability in the platform and so content filtering allows me to be able to show and restrict different actions and smoke spokes from users uh additionally so that's the actions part there additionally I can also control things like logic so when you think about flow designer you you've got those three tabs when we're adding a new activity in flows so each of those we can control what's in all three of those um and that's pretty great so I can control the actions the logic and the subflows available to the users based off of the content filtering and the things in the top right I get control with the feature access so how does all this work you might say and I'll answer with well let's go look at it let's look at it let's go look at it so if we return to an instance and I just need to move the interface just a teeny bit so I can find where I'm at all right here we are we're in a surface now instance now and I'm going to narrow down my menu to process uh so I should get process Automation and under flow Administration we're going to go down to content filtering rules so this uh table holds the rules um and I have already set up some rules then we're going to see how they work today so I have decided that the connect spoke um so we have a Spoke installed called connect um and I've decided here in this instance that I need to restrict the access uh to this spoke to a particular role and only that role so I've said up this filter rule um that's based off of this role and a resource definition and a resource definition helps me Define what this is filtering so this is whom it is filtering for and this is what it's filtering so let's drill into the resource definition to see what that is and it will uh be defined as uh the flow actions that are from this particular sco which is a Spoke so what you'll see in there is a condition Builder so you pick the table and I pick the flow actions table and then you build the conditions and my conditions for scope is the connection spoke and that will narrow down the three actions in that spoke uh to only be available for the users with the role ajb test let's give this page of full reload the cool part and maybe you have uh seen that in the list that we had before uh the feature access configuration that we do in that uh list where we add the roads to the different features those will also show here so the underlying architecture is the same for both of these features and it is good to note that it is a uh an architecture that we will be uh carrying over to other products as well but we do plan to improve on the interface because we know right now with the list and forums experience it's not very intuitive but we are planning to update that uh this is a safe harbor statement so you won't get any timeline on this for from me uh but we do want to make it uh a better experience uh but one of the main reasons why we're having this conversation today and why I wrote the uh the article is that I think this feature is very underrated and not many people have seen it before or understand how it works and how powerful it can be to filter these things down uh so especially for things like spokes uh consider spokes that are uh working with your HR Service delivery uh product right you don't want anybody ad just anybody to update users in your employee uh resource system uh that is just not something you want done uh and this is why you can have these uh uh these definitions and I see you found the page it works I I did um so this is that uh resource definition so it was application is the connect spoke and that gives me the three matching conditions so there are three actions that need that so what we can see is if I go and impersonate this user that I need to impersonate we're going to go impersonate uh e Eileen has that role um and so anyone without that role isn't going to be able to see it but Eileen will be able to see it and so I'm going to quickly be I I'm going to refresh my flow um because we need to refresh it because we changed who our user was and make sure that it understand stands that we should filter and that would take hopefully just a moment um and in this in the sake of time here I'm not going to show uh the negative case but be assured that anyone other than folks with that role are not going to be able to see the actions for The Connect SC spoke so if I filter my search actions so you see the little spinny right there what it's doing right then is going through all of those uh resource definitions and the filters that are applied for those and building the list of the ones that this user has access to and so you can see I can see these three and if I impersonated any of the other users that have access to flow designer um you would not be able to see these because uh they don't have that ability and one of the things I'd like to note is if you open in a flow that you have the ability to edit but it contains one of those things that you don't have permission uh to access so if I opened a flow that had the connect actions in it um and I wasn't a user who could use that that that flow becomes readon for me oh that's very neat just because it contains that so you can't go in and change one even if you have access to change that flow normally you wouldn't be able to change it because you don't have the ability to access that action and so it doesn't want you to be able to modify that flow because you aren't allowed that makes so much sense all right and so that is content filtering and I'm GNA hand it back to you for API access awesome thank you so much yeah I think uh feature access and content filtering is highly interested interesting but now we uh cross over from our second part to our third part into execution access so now that we've decided where we can build our uh workflows and how we can build our workflows we can now determine what our workflows can do and how they can run uh we have apis for each of our three products which have dependent on how long the products have been around a different uh amount of methods that we can make use of uh one of the larger uh sets of uh apis that we can use are in the flow designer space and the most uh most obvious one would be to run or trigger a flow and to do that we can do that either from a server side script or from a client side script with the flow API the handy part about flow designer is that it'll generate this code snippet for you uh so you don't have to write all of this and it gives you some uh instructions on what is expected for the inputs do you uh need to provide maybe a table or an object or a string as inputs and then you can decide whether you want to run your flow either in the background so asynchronously or in the foreground uh which is synchronously um to run a code snippet from a client script you'll need to use the Glide flow API over the flow API uh the Glide flow API over the flow API uh but again uh flow designer will create that code snippet for you and as far as I know uh client side scripts will run uh synchronously anyways uh to uh but to make this work and to use this you first have to uh activate the check box that says call B by client API and that that is a perlow setting that you can set in the flow properties uh from the overflow menu in the top right and then similarly to how you do for script includes yes exactly H so you first have to enable that and make sure that uh the flow knows that it uh is allowed to run in the client uh context and then for some very special use cases where you want to accelerate the flow execution even more more we do havequick methods to append to the flow API and this makes the flow execution faster because it does not create execution details and context records but it will uh still be locked so you will still know that the flow ran but it won't create any of the execution details and thus be a lot faster uh one Niche uh uh use case where this could be used is if you uh want to run a small this is important small subflow or an action from a uh B4 business role so since flow designer is currently uh only available asynchronously or in the uh after context uh this means that if you do want to run some logic in the before context before a database interaction you would still need to use a business rule and you could use the quick method uh to do that with flow designer um then we'll get over to process automation designer uh process automation designer has uh so far the most limited set of API um they're mostly uh uh really backend API that we might be uh using to uh run it to insert an optional activity into a running process um this API is being used in our uh Playbook uh experience component for example for the add activity uh um UI act um action that is in there Playbook action and then uh Playbook experience API has a couple of options to uh list uh running uh executions start or cancel executions and we're also um uh planning to add a restart API I believe that's scheduled for work uh for the Washington release but again Safe Harbor timelines may change uh but the restart uh option will be really handy for those use cases where you just have to go back um in a process and restart a phase for example a stage and then for decision uh the there are a number of API uh methods available for decision tables uh quite a lot actually which is really useful you can look up all of the things that make up a table you can choose to only look up rows you can choose to only look up um all of the results you can add and edit uh you can actually and delete uh rows or decisions or results or whatever through API there's a live coding happy hour session um linked in the center of excellence uh about using the uh decision table API to actually construct a whole decision table uh but the most useful ones that you will probably use are make a decision or make decisions uh so what it does is to either uh get the first decision that evaluates to true that's the same options that you can see in flow designer or get all decisions that evaluate to True which will output an array of result elements for you um because this is uh uh also a neat little thing that you would really like to not write yourself every time we're again Safe Harbor introducing a code snippet option similar to what we saw in uh flow designer earlier uh we will bring that to decision table uh to decision Builder as well which is also very handy and it'll just give you all the inputs some recommendations uh and also the outputs on how you want to use that uh so much for apis I think and I will hand it back over to you Andrew oh thank you Lisa now we're going to talk about uh run with rolls so um we would like to you know continue on that vein of you know that execution layer and what you can do there which is uh in flow designer we have this capability called run as and you have some choices there so if you run as a system user then you're effectively running as an admin and that mostly allows you access to write to nearly all of the service now tables uh and capabilities and I say nearly because there are times and places where you can't as admin access things so specifically when a scope has enabled application Administration that prevents an admin uh the admin role itself uh from being able to interact uh with those tables natively um as if we had acl's there so uh that that is definitely a time and place for that and we're actually going to see that in the demo um is HR is a good example of when the admin role doesn't have rights to write to the hrr tables um run as user so this is uh the ability to the user that is part of the that invokes the trigger for the flow so if you have an insert or created trigger um then the flow will run as that user that invoked the trigger um and when would this be useful well it certainly can be useful when uh you want to have access to something like an HR table so if any of the HR table users um are invoking triggers that then update HR table uh entries then running as that user is very handy um and it shows that it was from that user and grants the ability uh to write to those tables because it's running as that user and the last one is runs with rols and so this is a scenario where you don't want to run with as system um and you're kind of running as the user but you're adding a layer on top specifically for that flow to add an additional role so it's kind of like you're instantaneously granting a user a role running that flow and then removing that permission immediately before they can do anything else you might not you're you're not actually adding the role so don't be don't be alarmed about subscriptions or anything like that this is not it's not actually adding the role but you the flow the permission yes yes absolutely maybe I didn't make that as clear as we should um is it is as if you were doing that but you're not actually doing it so let's take a look at what that looks like in practice so I'm going to return to my handy dandy screen okay our last demo for the night will be to show a flow with runs with roll RS so what happens is in our flow right now if I go over to flow designer and take a look at our flow we have if the trigger is on an instant is created or updated where short description starts with invoke and then we update this HR case so most users are not going to be able to update an HR case uh under many scenarios so if uh specifically if I'm doing user who initiates the session so only users with HR roles that can already write to that table would this flow work for um so let's see that in practice we're going to come and use our test user here Aileen and she is going to create an incident with our trigger invoke the things and we're going to save that record that's going to trigger our flow um and it's going to update this HR case so we are going to refresh this HR case and we're gonna uh not expect to see any change in our HR case because the user doesn't have the rights to write to this table so we told it in the flow to update the description right here so if I return to flow designer and I take look the operations for this action I will see that it's in state error and the reason it's in state error is because that user does not have the access to that table it's prohibited by security rules so I can do one of two things and the thing that I'm going to do is adjust the properties to not run as a different user so I don't want to run it as system user need to run it as the HR writable role so that's going to be snore HR uncore core. Cas writer so I'm going to be able to write to HR cases only in the context of this one particular flow so when I hit update to that and then activate I'll be able to return to the same user in the same session even and perform that same activity and this time my flow should work so I'm going to reload the incident submission form I'm going to invoke with roll now when I hit save I should be able to now go check the execution record it has completed uh and no error this time so we expect now the description to contain I'm updated from flow and if we go to our HR case and we refresh that HR case we should see that completed now and it did I am updated from flow and so that concludes our demo thank you nice we do have a couple of minutes yes we still have a couple of minutes so we'll go through this one real quick before we head out into our conclusion uh so on the platform there has been a feature called restricted collar access for a while and you may think this is kind of left field what does it this have to do anything with workflow Automation in uh one of our recent uh releases I believe Tokyo Vancouver Tokyo of Vancouver uh we added the capability to choose um flows and flow actions as a source in this feature but you may ask what is this feature what does it do so if you are an application developer and you want to uh want to protect your application scope and all of the artifacts that are in your application scope you can do that with restrictor CER access privilege so this has something to do with the uh cross scope privileges that you may have heard of before uh but what this feature does it allows you to do a couple of things and that is either you can complete block all access from outside sources to your application things that can be tables that can be flows that can be actions that can be other logic uh automation on the platform and then uh you can also track those cross scope risk cross scope requests so you can uh set up an approval and say hey okay let me check this this uh new new flow that was created by my colleague and another team wants to access the data or the tables in my app and once you approve it then they their flow can do that again and again but there will be an approval first or uh the third the most permissive version would be to uh just notify you uh if an outside Source wants to access your things so this is also a way to restrict what your flows and processes can do in other application Scopes yeah and so to give you a bit of a conrete example in the flow that I was just showing that updated that HR table the flow itself was in the HR scope so it could do that if I had created that same exact flow with the same permissions and the same users were doing the activities but I was just in a different scope it would not work because in that instance I have it set up to restricted and it would then request the ability but it wouldn't have it until it's granted for it to execute against my tables and so I would get a different error inlow designer telling me that it's restricted through to cross scope access right that is that is a good example HR Scopes we are very prot protective of our employee data and that's why our uh HR Service delivery applications are set up in a way that only the very very minimum amount of access is being granted or if it needs to be granted there's an approval process to do that these restrictor call our access privileges can have different settings so it can be scope to scope uh so accessing one scope from another scope uh the access from a scope to a Target uh the access from a source to a scope or so source to Target while uh sources and targets can be any kinds of things so Source types can also be flows and flow actions and I think we made it we made it I am amazed 77 people made it to the end I can understand there's some uh some uh people being left behind I told you in advance this is an advanc topic this will be a little more difficult to follow but I did I'm very glad for everyone who did stay with us and uh uh now understands that we have three different levels on which we can restrict access to our workflows on the platform so some uh key takeaways and recommendations that we want to uh provide you with before uh uh giving you um giving you all of the resources is to to recap this to look at the recording to maybe read through the whole huge article series that I wrote uh so if you want to look up anything of what we talked about today I just posted the link to the articles in the center of excellence this is such a big topic it's actually three articles staying in the in the system of Threes uh when you're doing this uh do a good planning please uh consider any current access levels before implementing any of these things determine the right stakeholders and authorized approvers for Access levels this is uh for things like application collaboration it's important for things like the restricted color access and um make sure to establish clear communication with all stakeholders everybody who would be developing on your uh instances and so that they understand what they can do with the designers what workflows they can build uh execution pick the right features for your requirements remember that you can layer them you can uh combine them into a feature in a in an access set and then make sure to use catalog items and groups to manage this access so Grant and remove roles as needed um this will make your life so much easier than going in manually and adding them uh person by person lastly documentation as always uh make sure to do document the access restriction definitions and their implementation create dashboards and processes to audit and review those permissions and with that I will head over into thank yous we're at time uh just a quick uh shout out I think there weren't any complex questions but I did post the community post so if there are more questions please post them there and we'll try to answer them uh as as we go uh into the next weeks already shared the center of excellence with you uh that's your Hub to get uh updated on workflow automation um and the uh next sessions for the platform Academy will be uh moved out a little bit so the next uh in two weeks the next session is actually being moved by one week because there's Thanksgiving in the US uh so our next session will be on November 30 instead of the 23rd uh Jason the fever will join me with updates on playbook experience and on December 7th he will join me right right away again to talk about process automation designer updates so if today was interesting to you join us on these two dates as well and that is everything I have for today thank you so much H Andrew for joining me today thanks for everybody who joined us for this Academy I hope this session was helpful for you be just uh to uh fill out the survey and I will see you in three weeks thanks everybody thanks [Music] Andrew