Setting up users based on Direct Reports

Fairly new at the Administration side and learning as I go.  Currently all of our users are setup as Requestors (as is normal) but I would like to be able to have a rule for our provisioning (done through OneLogin) based on if their AD directReports attribute is not blank, assign them to the Service Task Users role.  Although there is a Reports To field for the user that pulls the Manager field from AD, it doesn't appear there is a field in SWSD that can list the user's direct reports.  Is there a way within SWSD to be able to display who a user's direct reports are, and also be able to setup a rule that if direct reports is not blank, to assign the Service Task Users role?

Thanks!

Parents
  • Howdy  

    I'm sure there is a way to do what you want in OneLogin, but I'm not a pro with OneLogin so it's hard for me to explain. The Service Task User(STU) role only adds the My Tasks section to the Portal, so you may consider just making all users as STUs rather than Requester. There is still no cost to be a STU, so many customers just choose this. Otherwise, maybe use a different logic if you're not having luck by targeting the AD directReports attribute, such as a separate Security Group. (maybe try OneLogin forums or support?)

    As for how to see all of someone's directs in the Service Desk, I'll past a screenshot below. It would still be a nice feature to add to the User Profile card, but that'll be a feature request. In the mean time:

    Setup>Users & Groups>Users - Using the "Reports to is", put in the manager you wish to see a list of their reports.

    I hope this helps!

  • Thanks for the reply!  Perhaps I'm going about it the wrong way and there is another way to tackle this.  The main thought for wanting to make staff that have direct reports into STU's would be so they are listed in the drop down for approvals.  Currently, if a staff member requests a catalog item that goes to their supervisor for approval, but that person is out of the office for whatever reason (PTO, leave of absence, sick, etc), we can't go in and change the approver to another as requestors aren't in that dropdown list within the ticket.  What we currently find ourselves doing is manually assigning the STU role to the backup approver, re-assign to them, then change their role back to Requestor.  Obviously another solution would be change the approval process to Requestors Manager or Requestors Managers Manager but that involves an organization policy change which can be daunting sometimes (although being looked into and working for).

    Hopefully that all makes sense for what ideally trying to accomplish and why (plus just having the direct reports show up on the contact card in the directory which would be an added bonus).

Reply
  • Thanks for the reply!  Perhaps I'm going about it the wrong way and there is another way to tackle this.  The main thought for wanting to make staff that have direct reports into STU's would be so they are listed in the drop down for approvals.  Currently, if a staff member requests a catalog item that goes to their supervisor for approval, but that person is out of the office for whatever reason (PTO, leave of absence, sick, etc), we can't go in and change the approver to another as requestors aren't in that dropdown list within the ticket.  What we currently find ourselves doing is manually assigning the STU role to the backup approver, re-assign to them, then change their role back to Requestor.  Obviously another solution would be change the approval process to Requestors Manager or Requestors Managers Manager but that involves an organization policy change which can be daunting sometimes (although being looked into and working for).

    Hopefully that all makes sense for what ideally trying to accomplish and why (plus just having the direct reports show up on the contact card in the directory which would be an added bonus).

Children
  • Makes sense!

    I think that if you changed the default role for all users to STU, this would solve all your problems. Again, there's no negative impact to giving them the STU role. Instead, you just avoid swapping them from Requester>STU>Requester again. 

    Also note, there are two features you could leverage in the specific scenario you gave. 

    1. User Impersonation
      1. This feature, which you may need to enable in setup, will allow you to impersonate someone and make changes on their behalf. (don't worry, everything you did is still captured in the audit log)
    2. Out-of-office message
      1. While you have them impersonated, you can set up their out-of-office settings, which includes setting a delegate. Be sure to select someone who has the permissions needed to view and work assignments, which is why making all end users a STU will also come in handy.