this video demonstrates how our beam allows servicenow customers to manage who has access to certain systems and locations first some terms our beam stands for role based entitlement access management an entitlement represents a system or service as an example splunk or tripwire or maximo or oracle financials whatever software or system you wish likewise it could also be a physical location like the dispatch center or the computer room or whatever location or area you wish to designate a role is a responsibility or a privilege associated with a given entitlement allowing people to request access to certain entitlements and being assigned specific roles completes the identity governance and administration function that our beam provides in other words our beam is an iga tool that provides the governance of the process for authorizing access it captures evidence needed for audits and reports for analysis organizing that information for quick access on the dashboard let's take a look at how all this works our beam allows you to define an entitlement and a few necessary attributes about that entitlement like the name of the entitlement who it's managed by groups for configuration and support and even business service associated with the entitlement you can create new entitlements update existing entitlements and even deactivate entitlements after setting up the entitlements that your organization wants to manage next comes defining the roles or privileges or responsibilities that you are interested in tracking for any given entitlement the simplicity and flexibility of allowing you to define the roles associated with an entitlement is powered by checklist pro another of tiger's servicenow store applications we think of our beam as an example of a pro code checklist pro implementation getting back to rb now that we have defined an entitlement and associated roles to it we can now manage who has access to white and what their level of access looks like in this example we're going to request access to maximo for able tutor using the manage entitlement access catalog item we first identify the entitlement then we choose the person needing access we can also specify if this person's access should be modeled after someone else in the organization we provide a reason or a justification for why this access is being requested and then offer the ability to re to the requester to identify which specific roles or privileges or responsibilities this person needs you'll notice that these roles are the ones we defined earlier after submitting this request our beam follows a two-step approval process the approval slash configuration team that was defined for this entitlement receives an approval request with a checklist representation of the roles in this example each member of the database group that we defined as the approval slash configuration team sees the same checklist as one person updates the list of roles all others from the group see those same updates that's checklist pro's shared checklist function in action after the approval configuration team makes any necessary updates to the requested access an approval passes it on to the manager of the entitlement in this case fred luddy the entitlement manager can also make any necessary adjustments to the requested access before either approving or rejecting the request in the entitlement managed if the entitlement manager approves the support team receives a task listing the authorized assets for this person and they can update the actual system and close the task our beam also provides a dashboard that shows the progress of all entitlement access requests it provides simple filtering and drill down capabilities allowing you to quickly determine who has access to what entitlements and who has access to what roles or responsibilities within each of those entitlements