How to allow access to records for a "proxy" user?

In every business, executives have Executive Admins or Personal Admins or Secretaries or whatever they may be called - but in every case they are someone who acts on behalf of another person - what I’ll call a “proxy”.

As far as i can tell, there is no way to create a “proxy” relationship in Knack. There is no way to to say “Jim Smith can also be known as Michelle Jones”. If something is owned by Jim Smith, or assigned to Jim Smith, or created by Jim Smith (or whatever relationship field is being used to filter a view), then there is no simple way to allow someone who isn’t Jim Smith but works on behalf of Jim Smith to see those records in a view.

I’ve toyed with ideas like establishing a proxy account connection field in every table and using record rules to set up the proxy relationship when records are created or updated, but that is somewhat static - when an EA gets sick or takes a vacation, it would require a wholesale replacement of the EA name with their temp replacement, then change it all back when they return. And what about where a pool of EAs operate across a pool of execs? Too much work.

So my question is: has anyone else found a way to resolve this challenge?

I did create somewhat of a solution in the past that might work for you. My use case was trying to view individual’s actual Annual Performance Plans exactly how they would see it with their data. It was easy for a supervisor because I had a two step relationship logged-in user>supervisor position>plan - easy to create a table for them to see all plans connected to their team members. But it was not easy for an HR Business Partner that we wanted to allow full visibility to support team members by looking at exactly what they saw. So we created a table for admins showing all plans, and then lots of links in that table that opened the edit pages that end users used.

As an extension to this - if your EAs are connected a person they support, you could have a connection from an EA user>EA position (incumbent user)>Executive position (support EA). Then create a table grid for a logged in EA to see the Executive position they support via logged-in user>EA position>Executive Positions. Then in that grid show the position and the Executive Position’s ‘current incumbent’ (an account connection) - with a link to a page of details about that Account. Then on that ‘Account’ page - create a bunch of grids/lists of things assigned to that user (e.g. tasks, actions) together with links to the forms the Executive users to actually take the action. You could also add reports they see together with the click-throughs to take action. That account page is basically mimicing what a user gets with grids/lists connected to the logged in user, and you have a gated way to get to it.

Of course anyone who finds the ID of the Executive could in theory open said page - but you could restrict access to it to an EA role.

What do you think?

Thanks Grant, your detailed response got me thinking about how I might approach this. I then realised it is pretty simple. So here is the approach that I took, in some detail, for anyone else who wants to do the same.

First, I created a new field in ACCOUNTS, a 1-many connection to itself (ACCOUNTS), called ALLOWED DELEGATES. I then created a form accessed from Account Settings to allow anyone to edit this field in their own (logged in user) account record, to add as many allowed delegates as they like.

In my example scenario, Jim Smith logs in and sets this field to Michelle Jones. This is the OFFER side of the delegation relationship …

(Note that I also created a Delegate user role which I give to Michelle Jones, and the selection is filtered by user role contains “Delegate”, so this limits who can be a delegate. But the main reason for the new user role is to provide access to a DELEGATE menu item, discussed below).

Second, I created another new field in ACCOUNTS, a 1-many connection to ACCOUNTS, called ACTIVE DELEGATIONS. I then created another form to allow anyone to edit this field in their own (logged in user) account. It is set up to only show those people who have made the “Offer” using the following restriction:

image

This way Michelle can ACCEPT to be a delegate for anyone who has allowed her to be one - ensuring its a two way agreement to act as a delegate. Once Michelle selects Jim and submits, she creates an ACTIVE DELEGATION.

To be able to use that Active Delegation, I created a DELEGATE menu with copies of the various scenes that I want a delegate to be able to see, for example a grid set up as:

This grid allows Michelle to see everything that Jim is responsible for - and anyone else who Michelle acts is an active delegate for.

THE ONLY HOLE IN THIS APPROACH is that Jim has no way to cleanly revoke Michelle’s access.

Taking away the “Allow” doesn’t impact the “Active” status. I can’t do it using record rules because that would remove every delegation from Michelle - because using record rules its all or nothing - there is no selective removal. Plus if Jim had more than one delegate, it would remove them too because the record rules will update EVERY delegate…

So instead I put up a big warning to Jim when he changes the “Allowed” settings to tell him to have the system admin remove Michelle’s active status - it could of course be an automated email to the system admin requesting the same.

If anyone has any thoughts about how to resolve this final piece of the puzzle I’m all ears.