How does the system deal with changes in manager? Are new instances of activities automatically created when a learner changes manager or is this managed separately with the 'manage participation' functionality? When various instances of an activity have been completed and the learner changes manager, can the previous instances be viewed by the new manager?
Hi Richard
The manager at the time of the activity generation is associated with the subject - any changes to the manager association will not be automatically applied to the activity.
It is possible to manually add the new manager as a participant so they can view the activity or wait for the regeneration of the activity if it is a repeating activity .The new manager will be included in the regenerated activity.
For more details see the personnel changes doc
Regards
Hi Craig,
Thank you for the very useful reply.
Is there a way to configure the system so a manager change triggers the assigned activity to be updated to the new manager? Or do you have any suggestions of a workaround for this process.
In our organisation manager changes happen on a regular basis. Our Supervision policy states that supervision is required every 8 weeks.
Where we see a problem is for example an employee has supervision with their manager, the activity is complete and the next supervision activity is then automatically created and assigned.
The employee then changes manager before the next supervision session occurs. We would find it difficult for an old manager to complete the assigned supervision activity to allow the system to moved it to the new manager. This could also cause issues as inaccurate data would be recorded in the system, as a supervision occurrence that never happened would be recorded.
With the amount of manager changes in our organisation it would be too much of an admin task to manually manage these changes.
Any suggestions would be greatly appreciated.
Thanks,
Carl
Hi Carl
I can't think of a way - although using audience of people who have new managers and creating an activity could work but having difficulty in how to create an audience rule and triggering the activity creation at the right time.
Will discuss with the Perform developers and they may have some ideas.
regards
Hi Craig,
Thank you again for the very quick reply.
That sounds an interesting idea, we will have a look ourselves. Hopefully the developers will also have some ideas. Will you update here if they do come up with anything for us to try?
I'm not sure if this is the right place to ask, but is there anything in Totara Learn V14 that allows for the uploading and storing of files? We can see the other evidence has moved to perform but we use this area to upload different learning staff have completed. We may not want to use perform for the initial V14 go live, does that mean staff can no longer see previous uploaded documents and will no longer have the ability to upload new ones?
Thanks,
Carl
We are very interested in this thread, based on significant issues with T10 appraisals and manager turnover. In my opinion a new manager in the hierarchy should take the place and all activity allocations from the previous manager, in a high turnover industry.
This is laborious to administer manually, if indeed that is possible.
Thank you
Hi Andrew.
To introduce myself, I'm the Totara Product Manager for Perform.
I think you are correct, this is laborious, and that is amplified in organisation where turn-over is a constant.
In v13+ performance activities (that replaces appraisals) uses the concept of subject and participant instances. So for any activity there is a subject (that receives the subject instance), and there are other participants (the respondents or view only participants) that receive participant instances.
It is possible to amend the participation? Yes
On the activity management page /mod/perform/manage/activity/index.php you can select manage participation.
This opens a page where you can modify subject and participants for the activity /mod/perform/manage/participation/participant_instances.php?activity_id=xx
In this example I am removing John M as Barry S's manager.
The unfortunate new is that at the moment this as all manual.
I'm planning to try and add some automation to this based on rules driven from job assignment, but this is at an early stage.
Thanks
Phil
Hi,
Picking up this thread again, very interested in hearing how it went for you? Did you find any good ways to handle this? Would love to here some ideas being shared here in this forum if possible.
Regards
Jonas
Hi Jonas Faxerin Barkman, Andrew Metcalfe, Carl Slater.
We're designing the solution for this now and I'd like to test some options with you to validate our designs.
When a user in a relationship with the subject (manager, managers manager, appraiser, and a new one we are adding direct report (the reverse of the manager relationship)) changes There are 2 actions we can take
Firstly. What do we do with the participant instance for the user that is leaving the relationship.
Options we see are:
Questions
We have examined at what level admin might apply these rules. Options are
Thanks
Hi Phil,
What do we do with the participant instance for the user that is leaving the relationship.
In most cases I would say you would follow option 3
Close and hide the instance for the outgoing participant. The outgoing relationship holder's participation should be retained in the response data, but is hidden on the UI. They do not see the participant instance in their activities.
So activities from old jobs don't clutter up the users view.
However, in some cases the relationship would stay with the old manager for a short period of time e.g. in the case where there is an appraisal end period just about to happen, it is normal for the old manager to complete that and then hand over to the new manager.
This would probably need to be handled a bit like the temp manager settings with a manual date entry that could be applied after the manager change (this would be too complicated for an HR system to have information about and send the right info), as it would be an agreement between the old and new managers. In my mind the new manager would assign the old manager the permission to be a joint participant over the whole of the Perform ‘estate’ (in one action) so that the old manager can do their final ‘bits’ but it also allows the current manager to work with the employee to set up their new activities.
What do we do with the participant instance for
the user that is entering the relationship.
The second option.
Create a participant instance for the incoming participant in the current activity. The incoming relationship holder should immediately participate in the activities for their team.
The employee can remove the old activities that no longer have any relevance to the new manager/role. In the case where a role hasn’t changed but the manager has, then the new manager will need to inherit the existing activities as they stand. That can be manually amended as part of the performance review process if needed.
CheersDavid
Hi David.
Thanks for the reply. Some comments
In my mind the new manager would assign the old manager the permission to be a joint participant over the whole of the Perform ‘estate’ (in one action) so that the old manager can do their final ‘bits’ but it also allows the current manager to work with the employee to set up their new activities.
While I understand the rationale this represents a significant change to how these relationships are managed. Currently this is solely determined by the user in the manager relationship on the Job assignment. I've looked at allowing many users in a role for 1 job assignment, but that flies headlong in the face of how Job assignments are used across the system. Allowing that could have unforeseen implications across the platform, so is very risky. I wouldn't want to blow up seminars on client sites accidentally.
We're also enabling the temp manager role (this is currently not used to generate a manager participant instance), perhaps rotating the outgoing manager into the temp_manager role with the expiry date is a solution.
One last question
Is it sufficient to provide these options at the site level, or would admins need to define this behaviour at the activity level?
One option we considered is to allow admin to set site default behaviour using the perform settings. Then provide those defaults on the activity, where the admin could override them for that specific activity.
Hi Phil,
What do we do with the participant instance for the user that is leaving the relationship:
In relation to what we have seen with customers using performance activities is that they would expect that:
What do we do with the participant instance for the user that is entering the relationship:
The "new manager" would be automatically assigned as a participant to the activity but this would only be required if:
At the site level the desired behaviour should be configurable but can be overridden in the activity instance - this gives the most flexibility
Temp managers
In relation to temporary managers, this is a tricky question and I can see why this has been excluded so far, but again perhaps this should be configurable:
Options I can see are:
I don't believe it would be wise to make an "old manager" a temp manager as this would have implications outside of the performance activity.
Hi Phil,
We've commenced using PERFORM in T14 and have just been bitten by this deficiency. I'm not aware of a business which won't be burned by it.
a) Since this thread was started, what's the latest treatment for this issue in T14? Is there a stopgap automation solution?
b) Will there be a backport bugfix to T14 ?
c) Could you please confirm that it is fully resolved in T16?
d) On a side note, has the behaviour which requires both manager and appraiser to interact with an activity to close it been fixed?
e) Is there work on behavioural documentation of PERFORM so that activities can be designed with confidence? (same for certification engine)
Thanks Phil
regards, Andrew
Hi Andrew Metcalfe.
To answer your questions.
a) Since this thread was started, what's the latest treatment for this issue in T14? Is there a stopgap automation solution?
As I said to Felix fundamentally backporting improvements to previous versions dilutes the value of later releases.
I do understand that upgrade is not just about deciding to upgrade the code, there's organisational issues in play here as well. However, the impact of migrating between the TXP versions is low. Do you have to migrate to 14? Is going all the way to 16 an option?
b) Will there be a backport bugfix to T14?
See above. I'll add to this that if upgrading to 16 is not viable for our NHS customers I will consider the impact of this. e.g. We backported the v16 ability to delete individuals to 13 because this mitigated a privacy risk
c) Could you please confirm that it is fully resolved in T16?
The functionality we deployed has had no reported bugs and works as designed.
In relation to the specific case you noted “In my opinion a new manager in the hierarchy should take the place and all activity allocations from the previous manager, in a high turnover industry.” You can set that the new manager is added to the activity, and that the old manager’s participation is closed. You can also close and hide empty responses in v16, so if the first manager has not responded no-one will see their empty response.
There were 2 ideas proposed in the feedback that we did not implement. These are in the thread.
d) On a side note, has the behaviour which requires both manager and appraiser to interact with an activity to close it been fixed?
Whether participants MUST interact with an activity is determined by whether response is optional. Participation is set at the section level. If you want actors in the activity to behave independently then you can put their respective questions in separate sections. If I’m missing the point please can you give an example.
e) Is there work on behavioural documentation of PERFORM so that activities can be designed with confidence? (same for certification engine)
This is a problem we have recognised. We’re working on webinars to address this. If there are specific use cases you like to have described let us know. We want to build more use case specific instruction.
Hi Phil,
Re
We're also enabling the temp manager role (this is currently not used to generate a manager participant instance), perhaps rotating the outgoing manager into the temp_manager role with the expiry date is a solution.
It’s not something that happens all the time but I know that I’ve been asked to complete my old line reports reviews even though I don’t currently manage them as I’ve got the prior knowledge to complete the appraisal cycle. It’s probably not the end of the world for the old manager to have a conversation with the new manager and tell them what their thoughts are so the new manager can enter that into the system.
Re your last question… Sorry I thought I’d answered that, but I obviously only did that in my head!
Your solution of setting a site level default and allowing overrides later sounds like a sensible solution as it gives flexibility.
cheers
David
Hi Phil,
Happy to hear that the solution is being designed. I was wondering if there is any indication yet on when this feature will become available, or which release it will be included in?
Kind regards,
Felix
Hi Felix.
It'll be part of v16.
We're proposing to being work on this feature in 2 weeks. I'll also do another post of designs we've developed in the prev 6 weeks for validation.
As a teaser these features are:
Thank you for the update Phil.
Is my understanding correct that it will then also be packaged into minor releases for v13, v14 and v15 (at the time when v16 becomes available?)
Kind regards,
Felix
Hello Phil,
Just checking to see if this feature is still being scheduled to be released with v16 as you mentioned earlier, and whether that is estimated to be available in April this year? I'm assuming that it will also be available as a minor release for TXP13 and TXP14 at the same time?
Is there a possibility for the feature to be released at an earlier date, as it's a much needed feature for some clients that have to handle frequent manager changes.
Kind regards,
Felix
Hi Felix. I wasn't considering backporting this, or a point release. However I will be swayed by partner feedback.
Regarding a point release. We have closed for the Feb point release so that's not an option. So all that is left is March and to be eligible this solution world need to merged by mid march. As we're doing this work now that feels doable, but I haven't discussed that with the Dev team either.
If this idea gets immediate support I'll try as I understand the importance.
If we do this work it will displace something else (like incorporating temp managers) from the release.
Thank you for the update Phil. Good to hear that there's a chance that these might be included for the March point release, as any earlier release for TXP13, TXP14 and TXP15 would provide relief for admins who receive very frequent requests to manually make the changes.
Kind regards,
Felix
Hi Phil,
I was wondering, since TXP16 was released recently, whether this particular change was (or is in the process of being) backported to TXP13, TXP14 and TXP15 in one of the upcoming point releases?
Kind regards,
Felix
Hi Felix. No we've no intention of doing that. Doing that dilutes the value in the new releases too much. So unless there's a critical issue we need to address, bug etc by policy we won't backport new features.
Hi Phil,
Important to close and hide the instance for the outgoing participant. The “old manager” shouldn’t have access to or see the old instances for their former employee.
If creation range is open and the prior instance (with the old manager) isn´t completed, there should be created a new one with the new manager for the employee.
To make it easy it should be 1. At site level. But I even more like this option that you mentioned:
One option we considered is to allow admin to set site default behavior using the perform settings. Then provide those defaults on the activity, where the admin could override them for that specific activity.
Thanks!
Thank you
Hi Phil,
Please find the responses below:
What do we do with the participant instance for the user that is leaving the relationship –
· 3 - The relationship between the manager and the user is no longer applicable, therefore this should not be available to view
What do we do with the participant instance for the user that is entering the relationship –
· 2 - This should be created instantly for the new relationship, if this is not required as in v16, the instance can then be removed
We have examined at what level admin might apply these rules –
· 3 - Site settings to define the activities and if this requires to be overridden by admin, this gives admins the permission to change as required
Kind regards
Gemma
Hi all.
We've taken your feedback and I'd like now to test the designs we're proposing.
See TL-31252
We're proposing 2 levels of setting. in TL-33432
The first will be a site setting that will determine the default behaviour across all open activities on the site.
Then in TL-TL-33433 we extend those setting to the admin activity config whre they can override the default settings per activity
I'd appreciate your feedback.
Cheers
Hi Phil,
Great to see this going forward, thank you. The design looks good.
Two question just to clarify:
Hi Jonas
in response to your 2 questions:
Hi all.
I want to clarify a subtlety that we're implementing for these changes in regard to the temporary manager job assignment.
As I've discussed we're implementing features to allow admin to control how participant instances are added, closed, closed and hidden when the user linked to a job assignment relationship changes e.g the subject's manager changes.
In addition to this we've also incorporated the temporary manager within the job assignment relationships Perform uses.
So when a temporary manager job assignment relationship is added a manager instance will be created for that user. AND When the temporary manager job assignment reaches its end date that job assignment is removed (by the system, please note this has always been true);
THUS,
if dynamic relationship is set ON we will recognise that the the temporary manager's job assignment has changed and the instance will be closed, or closed and hidden (depending on how admin has configured the behaviour).
Any comments are appreciated.
Hi Phil
It is music to my ears that something is being done about this, as many have pointed out any change in Manager at this point is very Admin heavy. Please could you give me an ETA on when these changes will be coming in, as at the moment I'm doing it all manually and losing my hair :).
Many thanks
Hi Paul. Yes, its pretty obvious isn't it. I'm a little ashamed that I didn't recognise these participation management features as primary needs until now. A good sign for our growing product management practice and its impact on prioritisation.
This was released in v16. So is available now.
