Skip to main content

Hi everyone - Hope you're good.

One pain point for me building our suite of interfaces, is the inability to use the 'User' field (mainly Assignees for tasks, projects in our example) to it's full potential in a number of scenarios.

The disconnect from a 'user' in Airtable, eg) someone I have invited to the platform and a 'record' in a Team / team members table that you can assign to a team / task can't be an oversight? 
You can't make a 'User' field as a Primary field, so you have to have another field with the name / id duplicated.

Some specific interfacing examples:

- Kanban view: You can't use the User field as the stacking field, in order to view a team's tasks, and drag and drop between the team members 
- Gallery view: You can't use the User field as the Primary field

I'd love to see how anyone has worked around this, especially in the case of a clean way to delegate tasks to users, with some visibility of the user's current workload / capacity.  I've toyed around with grouped timeline & grid views, but nothing that has got my fellow team managers excited yet!

Cheers!

Ross

Definitely agree. 

I think it'd be a great move to be able to sync Airtable workspace users as records.

Almost every project that as a Users/People/Staff table needs to store data about that user – which means the flow is always:

  1. New user has a base/interfaces shared with them
  2. Manually create same that person again in your users table

Offboarding is also duplicated effort as you need to unshare and remove/archive that airtable record. Easy to forget to do both and you are leaking data to an ex-employee etc.

Maybe a better way to run things is to be able to use an automation to a base where the actions are to share that base or select interfaces with the new record – again, halving the manual effort required.

Definitely agree. 

I think it'd be a great move to be able to sync Airtable workspace users as records.

Almost every project that as a Users/People/Staff table needs to store data about that user – which means the flow is always:

  1. New user has a base/interfaces shared with them
  2. Manually create same that person again in your users table

Offboarding is also duplicated effort as you need to unshare and remove/archive that airtable record. Easy to forget to do both and you are leaking data to an ex-employee etc.

Maybe a better way to run things is to be able to use an automation to a base where the actions are to share that base or select interfaces with the new record – again, halving the manual effort required.


We are running a 100+ User enterprise environment and this has been one of the biggest contention points. What I ultimately did was setup a User Management base & wrote a handful of enterprise api scripts to run multiple times a day. This will keep my user list updated with all of our organizations managed users, but also allows us to create additional fields to update with associated data, for example, the slack ID of our users so that we can automate Direct Message slacks. This doesn't solve for the problem of collaborator, but as long as the user management page has their user ID on it, you can create an automation to automatically link the User in the user management table based off the user ID associated with the collaborator. Its been great while we are awaiting a OOTB solution.

We are running a 100+ User enterprise environment and this has been one of the biggest contention points. What I ultimately did was setup a User Management base & wrote a handful of enterprise api scripts to run multiple times a day. This will keep my user list updated with all of our organizations managed users, but also allows us to create additional fields to update with associated data, for example, the slack ID of our users so that we can automate Direct Message slacks. This doesn't solve for the problem of collaborator, but as long as the user management page has their user ID on it, you can create an automation to automatically link the User in the user management table based off the user ID associated with the collaborator. Its been great while we are awaiting a OOTB solution.


@Joe_Svingala  would love a walkthrough of what you've put together there. Would you be able to share a loom to demonstrate?

@Joe_Svingala  would love a walkthrough of what you've put together there. Would you be able to share a loom to demonstrate?


Same! 

We are running a 100+ User enterprise environment and this has been one of the biggest contention points. What I ultimately did was setup a User Management base & wrote a handful of enterprise api scripts to run multiple times a day. This will keep my user list updated with all of our organizations managed users, but also allows us to create additional fields to update with associated data, for example, the slack ID of our users so that we can automate Direct Message slacks. This doesn't solve for the problem of collaborator, but as long as the user management page has their user ID on it, you can create an automation to automatically link the User in the user management table based off the user ID associated with the collaborator. Its been great while we are awaiting a OOTB solution.


This is a fantastic idea.

Terms & ConditionsCookie settings