Have you ever gone to add a user to a role and been overwelmed by all the indirect entitlements the user receives because 
With a focus on helping organizations achieve business agility – we are proud to announce the release of the simplified approval improvement in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release .
Most approvers are not spending all day in the RSA Identity Governance and Lifecycle product and they are being involved in the process for business reasons. In this scenario, 99% of the time we probably are asking an approver the question: Should this user be a <role name>? For example, if someone joins my team, I am likely being asked if they should be a developer and my job is to approve or reject that. What it means to be a developer is an entirely different problem likely maintained by a very different process. For this reason, we have added a new setting to approval workflows and changed the default for the out of the box approval workflows and any new approval workflows that are created to not include indirect entitlements by default. Existing customer approval workflows are not touched.
You may want to reevaluate your approval process though and decide if you really want your approvers worrying about indirects either. Do you want them focused on the simple question: Should this user be a developer or do you want them really approving the one hundred other entitlements the user will receive because they are a developer?
