Skip to main content
Open

Delegate / proxy feature to transfer user rights in case of holidays or sickness

Related products:Intelligent Application Manager
  • Frank Junger
  • Suleyman
  • Ruben_Kwant
  • Vince D
  • Eric F
    Eric F
  • JacobVenema
  • Ionut
    Ionut
  • BjornPmm
  • pietervasbinder

Not sure whether Thinkwise should deliver this feature or not, but just wanted to post this Idea to see if other TW-customers needs these kind of functionality too.


Delegation functionality
A feature in a software system that allows users to define their holiday or sickness period and transfer their user rights to a dedicated colleague is typically referred to as "delegation" or "proxy" functionality. This feature is crucial for ensuring business continuity and workflow efficiency in an organization.

Key Components and Functionality

  1. User Interface for Setting Delegation:
    • Period Definition: Users can specify the start and end dates for their holiday or sickness period.
    • Select Delegate: Users choose a colleague to whom their rights and responsibilities will be transferred during their absence.
    • Reason/Notes: Optionally, users can provide a reason for the delegation (e.g., holiday, medical leave).
  2. Delegation Rules and Permissions:
    • Granular Permission Control: Users should be able to select which rights and responsibilities are transferred. For example, they might delegate the ability to approve certain workflows but retain access to sensitive information.
    • Temporary Access: The system should ensure that the delegate only has access for the specified period and automatically revoke access once the period ends.
  3. Optional: Notification and Confirmation:
    • Notifications: Both the original user and the delegate should receive notifications about the delegation setup, including any changes or cancellations.
    • Confirmation: The delegate may need to confirm acceptance of the delegated responsibilities.
  4. Audit and Security:
    • Audit Logs: The system should log all delegation activities for security and compliance purposes.
    • Security Checks: Regular checks to ensure that delegations do not create security risks or conflicts of interest.

Benefits

  1. Business Continuity:
    • Ensures that critical tasks and approvals are not delayed due to a user's absence.
    • Maintains workflow efficiency by allowing colleagues to handle responsibilities seamlessly.
  2. Improved Flexibility:
    • Users can take time off without worrying about pending tasks or responsibilities.
    • Provides flexibility in managing unexpected absences due to sickness or emergencies.
  3. Enhanced Collaboration:
    • Promotes a collaborative work environment where colleagues can support each other.
    • Helps in distributing workload effectively during peak times or staff shortages.

Conclusion

A well-implemented delegation feature enhances productivity, ensures continuity, and provides flexibility in managing absences. It is a vital component for modern software systems, particularly in organizations that require constant workflow and decision-making processes. Ensuring security, ease of use, and seamless integration are critical factors for the success of this feature.

Did this topic help you find an answer to your question?

4 replies

Jeroen van den Belt
Administrator
Forum|alt.badge.img+9
NewOpen

Anne Buit
Community Manager
Forum|alt.badge.img+5
  • Community Manager
  • 653 replies
  • October 11, 2024

Cool idea!

There is a great opportunity to piggy-back this feature on existing Simulation capabilities.

Simulation already allows for users to work with applications as if they were a different user. Within application logic, distinction can already be made to obtain the ‘original’ user, for instance for logging purposes.

The tsf_user() function currently returns the simulated user in favor of the original user, allowing data authorization to be included in simulation and delegation. The tsf_original_login() function always returns the original user, allowing logging and audition, as well as more tight data authorization which must remain active even during simulation or delegation.

Naturally, to allow for simulation to become the basis for delegation, we’d need more fine-grained control for this form of simulation. This would include an administration in IAM of which user(s), which available roles as well as the timeframe delegation would be active. This can include the notification options which were suggested.

I’d certainly base this around roles, comparable to how Personal Access Tokens (PATs) can be created by an end user.

Comparable to simulation, the delegated user would have to manually choose to ‘switch’ from his or her own account to the user account to perform the delegated tasks. This could be incorporated in the GUI as a first-class feature.

Some questions remain. I’m curious to hear any suggestions on the following:

  • To which extent would users be able to freely set up delegation themselves? Would administrators have to turn on this feature for specific users? And allow this for certain applications, a subset of possible roles, possibly even limited by developers marking certain roles to be allowed in delegation, comparable to PATs? Note that the developers will have to consider the distinction between tsf_user and tsf_original_login.
  • I’m assuming that e-mails and notifications sent from the system to the user who delegated tasks will not reach the user performing the delegated tasks. After all, it is virtually impossible to distinguish which notifications are relevant to the subset of tasks. Likewise, you’ll still receive your own notifications and emails from the system. This may be a bit confusing.
  • How do user preferences work while working with on delegated tasks? Are they the user preferences of the user account delegating tasks or are they your own?
  • How will a user find the user account to delegate to? This may require listing of user accounts (possibly limited to tenant) which may be a privacy and security vulnerability vector.
  • Do limitations in simultaneous application access still apply? An application can be configured to have a maximum number of sessions per account. Is the original account or the delegated account counted in this scenario?
  • Should security checks consider active access obtained through delegation and/or potential access obtained though delegation?

Forum|alt.badge.img+2
  • Author
  • Sidekick
  • 14 replies
  • October 11, 2024
  • To which extent would users be able to freely set up delegation themselves? Would administrators have to turn on this feature for specific users? And allow this for certain applications, a subset of possible roles, possibly even limited by developers marking certain roles to be allowed in delegation, comparable to PATs? Note that the developers will have to consider the distinction between tsf_user and tsf_original_login.

-In terms of flexibility & efficiency, I would say that users should be able to set up delegation by themselves. Especially in the last days before holiday leave, it will be very practical to easily activate the delegation on time (like your out-of-office setting).

-Not sure about more limitations like applications (since we only have 1 :) ), but I would say that the delegator should be able to select which "Active User Groups” they want to delegate, since these are a logical set of roles in order to fullfill a complete set of ‘duties’ in the ERP system. It could be very unpractical if the user should fulfill his own tasks first and then needs to log out + simulate to fullfill his colleagues tasks. Best option is to only login once, and execute all tasks for yourself + colleagues who has delegated some stuff.

  • I’m assuming that e-mails and notifications sent from the system to the user who delegated tasks will not reach the user performing the delegated tasks. After all, it is virtually impossible to distinguish which notifications are relevant to the subset of tasks. Likewise, you’ll still receive your own notifications and emails from the system. This may be a bit confusing.

-Emails / notifications are not a must for 1.0 from my point of view, but since IAM has these options, it could be incorporated as well. Since we already have a existing approval workflow with Teams notifications, the acceptance of any ‘delegation’ request could be integrated within this logic as well. 

  • How do user preferences work while working with on delegated tasks? Are they the user preferences of the user account delegating tasks or are they your own?

-User prefs we have are dark mode / density. For me it is logical to stick to the user prefs of the original user.

  • How will a user find the user account to delegate to? This may require listing of user accounts (possibly limited to tenant) which may be a privacy and security vulnerability vector.

-The user list could be limited by taking their ‘IAM company or IAM department’ into account, to prevent showing a complete list of users.

  • Do limitations in simultaneous application access still apply? An application can be configured to have a maximum number of sessions per account. Is the original account or the delegated account counted in this scenario?

-I would say that this should not be an issue, refer to my previous comment (nr 2). 

  • Should security checks consider active access obtained through delegation and/or potential access obtained though delegation?

-Actually, they should show failure based on what the original user sees (together with its extra user groups). 


  • Rookie
  • 2 replies
  • February 27, 2025

Should be nice to see this implemented before the coming holiday season? Any updates on this?


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings