on 20-09-2017 04:46 PM
One of our firm's users tried to open a workspace to create a NSW caveat and got the following error message:"You do not have access to the default Workgroup for this Jurisdiction / Role combination." The user does not have access to our Primary Default workgroup but does have access to the workgroup for her team. As a work around one of our subscriber administrators opened the workspace for the user and then moved the workspace to the workgroup for the user's team. However, this is not a viable long term solution.
Why was the user unable to create the workspace within the workgroup for her team (to which she definitely has access)?
Another user tried to open a workspace for a Victorian transaction and discovered that he was unable to set up a workspace in the rule of applicant or CT controller. All other roles were ok. Why is this happening?
We have not set up any automated rules for our workgroups so there should not be any limitations on the types of roles and jurisdictions that users can establish workspaces for.
on 22-09-2017 11:00 AM
I’ve had a look at your setup and can see than you’ve created state-based workgroups. Which is a very most common configuration. There’s one more thing you need to do to make this setup work, which is to define ‘Default Workgroup’ rules to ensure that NSW work is routed to your NSW workgroup, Vic work to your Vic workgroup etc.
Out of the box, only the ‘Primary Default Workgroup’ has a rule attached to it. And that rule is a “catch-all” (all jurisdictions, all roles, with or without Financial Settlement). When creating a workspace, PEXA checks whether the user is a member of the workgroup that matches the parameters of the workspace being created. In your case, the NSW Caveat workspace matched with the catch-all ‘Primary Default Workgroup’ (because there are no other rules defined). As the user wasn’t a member of the ‘Primary Default Workgroup’, they were shown the error and prevented from creating the workspace.
We’ve built PEXA this way to ensure a hard separation between the workgroups (teams). Users that are members of your NSW workgroup shouldn’t be able to create Vic workspaces, and vice versa. (If they do need to, then they can be added to both workgroups.)
So all you need to do now is define default rules for each workgroup. You can do this by going to Administrator Tools -> Manage Workgroups -> Manage Default Workgroups -> Add Rule.
(Where you have multiple workgroups for a particular state, use the Role and Financial Settlement parameters to differentiate between them.)
Once set up in this way you’ll also notice that workspace invitations will route to the appropriate workgroups, and only users of those workgroups will be able to view and accept them.
I hope my answer is helpful. We’ve built a lot of smarts into the workgroup functionality, but by doing so have made it a bit complex and therefore tough to understand. We’re looking at how we can make it a bit simpler.
Product Owner, Practitioner Service
on 26-09-2017 05:02 PM
Thanks for the reply. We had arranged the set up we have for the following reasons:
1. We have actually set up team based (rather than state based) workgroups, for internal reasons.
2. We need all workgroups to be able to open workspaces in all roles, in all jurisdictions, both with and without financial settlement. For example, our teams in NSW need to be able to do all types of VIC work, and vice versa, and we do NOT want VIC workspace invitations to be automatically routed to VIC workgroups.
3. We want to avoid needing to add people to more than one workgroup.
4. We want to limit the number of people in the Primary Default workgroup, again for internal reasons. That workgroup should merely serve as a conduit for invitations received externally.
Could you please urgently clarify whether and how it is possible to ensure that all workgroups can open workspaces in all roles, in all roles, in all jurisdictions, both with and without financial settlement. Please feel free to contact me offline if this is easier.
on 26-09-2017 07:40 PM
Because we've built access controls and permissions into workgroups based on their default rules, I'm not sure we'll be able to satisfy all the requirements you've listed.
(We're exploring ways to loosen these controls in another community thread: Workgroups - view options)
I have a few suggestions on how you could set your workgroups up, but unfortunately each of these breaks at least one of your requirements.
Probably easier to discuss offline. I'll be in touch tomorrow.
Sorry my original suggestion missed the mark.
Product Owner, Practitioner Services