What is OKTA?
OKTA is a different type of active directory setup. Until now we had the setup for Azure AD, and now we also have the the setup for OKTA.
Release Notes do not cover change SL-9268 (INTERNAL). As a training user, I want already created Tasks for Training to be considered the same Task if that task Title and Task Supervisor are the same. Was this change released with the update or not?
This task won't be carried out in this release because we're walking back the training task functionality. The idea behind this task was to help out so that you could repeat training tasks as one.
But we're walking back this training task functionality, so for now you needn't worry about this specific internal task. We'll figure out a better way of implementing the changes to the training tasks in the future.
Is there an easy way to link URS items with change items (SL-IDs)? Unfortunately, the Traceability Matrix does not list SL IDs.
SL IDs should not be that important, because these are Jira Tasks and from a validation perspective, we should have the URS IDs available. That is what user requirements have been changed or added from a validation perspective because we have traceability in the validation documentation.
I would say that you can ignore the SL IDs and focus more on the URS IDs for your documentation validation perspective as well as the traceability perspective.
Will the Effectiveness Check apply to ongoing change? Will its closure be done per a different QA?
Firstly, if I understood the question correctly, you're asking "What will happen with those change requests that you currently have in the system, when we introduce the new status, will you be able to perform an effectiveness check?"
I would say yes, as they aren't closed. If they're assigned by QA, I would say that you should be able to see the new options, once we release them into the production environment. But I will confirm this.
About the closure, it depends a little bit on your process. We have customers who would rather have 2 different people from the QA team working on the effectiveness check, so as not to create a bottleneck with one of them. That means that one QA can actually sign off the effectiveness check itself, update the conclusion to the effectiveness check, and then escalate to effectiveness check pending approval, where another QA can then approve whatever was carried out by the first QA and finally set the effectiveness check to close.
Effectiveness check pending approval status is not mandatory, you can skip it if it's the same person who signs off on the effectiveness check. But if, according to your process, you'd rather have 2, then there's no problem. You simply configure two, one does the conclusion and the other approves it.
So do we need to configure 2 QA in the change?
It depends on you. You can just have one user configured as QA, which is the minimum required. But if you have a high volume of change requests, and you can see that one QA person is all of a sudden required to do a lot of effectiveness checks that are ongoing at the same time, it could be useful to assign 2 people as QA in those different effectiveness checks and then divide them up between you in a way that will allow you to work more effectively without creating a bottleneck.
Will this new feature be valid for orphaned documents that already exist in the system?
Yes, it will still be valid for orphaned documents that already exist in the system to do bulk reconciliation.
