Leasing Functionality Clarification Needed

[elewis]

Hello - This is my second post on here as I am new to the Flexera/App Portal space and I have some clarification needed for a functionality on Leasing in App Portal v. 2019 R1 14.0.0.0.

We have a Leased catalog item that has the option enabled:

1. Allow user to extend lease when approval is required
2. Allow extension only up to maximum days allowed

This catalog item does require approval for Install.

For this catalog item, an approved Install request adds user Machine to an AD group. Upon lease expiring, an Uninstall request is automatically triggered, user Machine is removed from AD group.

First Clarification: As per my understanding - let's assume a user has Request A whose lease is about to expire 20 days from today. To renew, user is currently creating an entirely new request, Request B. This request is approved today and user Machine remains in AD group. However, Request A hasn't expired yet. So once Request A DOES expire after Request B has been approved, Request A expiration/Uninstall actually removes User machine from AD group and thus, overwrites what Request B was supposed to do - maintain user in AD group.

Is this understanding correct as per what App Portal functionality does here? It seems App Portal doesn't associate the lease to the user/machine, rather associates the lease to the request itself. Hence this potential gap that can occur.

Next: need to clarify: for the options we have enabled, if a User does go into Request A and instead extends their Lease rather than create Request B, this extension step will NOT retrigger approvals to the Approval process configured. Is this correct?

Our use case is:

1. that we do not want a user extending their lease without it going through approvals first,
2. and we also don't want the leasing gap to occur where they create their new request before their previous one expires and thus has an issue.

If my understanding on both above points is correct, we are considering educating our special approver to review a "Request B" request scenario and either cancel that request and extend the Request A lease themselves, or possibly cancel the Request A and proceed with Request B… Any thoughts on this solution also would be much appreciated. 🙂

[CharlesW · Accepted solution]

You are correct in your observation that leasing is done at the request level, rather than considering the target user/machine... As such, a user could potentially request the same leased catalog item multiple times for different requests.. Assuming that this is a software catalog item, you might prevent this behavior by going to settings-Website->catalog behavior, and selecting "Block catalog item reorder during waiting period".. You'd also want to set the "Catalog item reorder waiting period (in days)" to the lease duration.. It should be noted that this would be applicable to all requests, not just a leased request..  Another possibility would be to add a visibility condition to the leased catalog item. This visibility condition would evaluate AD group membership.. You could set this as an exclude condition, so that if the user was in the AD group, then the catalog item would not be visible.. You are going to be limited here to users, as App Portal will not evaluate device membership in AD groups.. Another possibility would be to use a SCCM collection condition, which would allow you potentially set visibility on a machine name.

Selecting the "Allow user to extend lease when approval is required" basically allows a user to extend the lease, even if the catalog item requires approval.. It will not initiate the approval process again.. 

[CharlesW · Accepted solution]

You are correct in your observation that leasing is done at the request level, rather than considering the target user/machine... As such, a user could potentially request the same leased catalog item multiple times for different requests.. Assuming that this is a software catalog item, you might prevent this behavior by going to settings-Website->catalog behavior, and selecting "Block catalog item reorder during waiting period".. You'd also want to set the "Catalog item reorder waiting period (in days)" to the lease duration.. It should be noted that this would be applicable to all requests, not just a leased request..  Another possibility would be to add a visibility condition to the leased catalog item. This visibility condition would evaluate AD group membership.. You could set this as an exclude condition, so that if the user was in the AD group, then the catalog item would not be visible.. You are going to be limited here to users, as App Portal will not evaluate device membership in AD groups.. Another possibility would be to use a SCCM collection condition, which would allow you potentially set visibility on a machine name.

Selecting the "Allow user to extend lease when approval is required" basically allows a user to extend the lease, even if the catalog item requires approval.. It will not initiate the approval process again.. 

[jdempsey · Accepted solution]

I like the idea of an AD group-based visibility condition.  One other thought related to the "overlapping requests"... I'm assuming in your catalog item, you have a web service or script command action attached to the On Uninstall event that does the AD group removal (as far as I'm aware, App Portal does not natively have the removal function).  If that's the case, perhaps you could put some additional logic in your action that checks to see if there is a new request for the same software/user/device before removing the user/device from the AD group.  Then you'd probably also need another action on the On Request Rejected event that looks to see if the user/device is already in the corresponding AD group and remove them (this would cover the case where the user requests an "extension" and the extension request is rejected).

[elewis]

Thanks for the quick response on this! Super helpful to know I was on the right track with understanding current functionality/gaps. I'll also take note of your suggestions and review internally.