Table of Contents

The ID of the user is best described as a personal identification number. The user’s ID is unique within the team and always belongs to one team member.

With the help of User ID you can set dynamic filters in SeaTable, which in certain situations is more suitable than filtering by the creator column . In this article we will present you the advantages and disadvantages of filters with User ID.

If you want to know how to change the user ID of a team member, you can find the answer in this help article .

In SeaTable you can use the filter “is current user’s ID” for each text column. This creates a dynamic filter that only shows entries where the own user ’s ID is stored in the corresponding text column .

Example filter by user ID

Suppose you have three employees and they have the following IDs:

  • Markus with the ID 20
  • Helmut with ID 23
  • Sven with ID 56

Now, for example, if you maintain a table in which you enter the open tasks of your three employees and define such a filter, …

Defined filter according to the user ID in the use case

… will …

  •  … Markus will only see the entries where his individual User-ID 20 is entered in the corresponding column.

Table view of Markus in concrete use case

  •  … Helmut will only see the entries where his individual user ID 23 is entered in the corresponding column.
  •  … Sven will only see the entries where his individual user ID 56 is entered in the corresponding column.

The alternative would be to filter by the Creator column, which also offer dynamic filtering options. However, these two columns have the following disadvantages:

  • The value in the creator column cannot be changed later. Once set, the value always remains the same. This would be problematic in the above example because the creator of the tasks is not the employee.
  • The Staff column can only be filled if a team member has at least read access to Base. Especially when using the Universal App , this may not be desired.
  • The employee column cannot be filled automatically via web form. However, the ID of the user can be set as default value by assigning {creator.id}.

You can adjust the user ID entered in the text column at any time. So if you want to change the assignment of a row afterwards, filtering by the user ID is very helpful.

Imagine a to-do list that you use to enter tasks in SeaTable. The creator column is out of the question for assigning the responsible person, because then the team members could only create tasks and assign them to themselves. The employee column is the most obvious solution, but only if all team members have at least read access to Base. If the team members should not be able to see the tasks of their colleagues under any circumstances, it is recommended to use the user ID to assign the responsible person.

If you assign the open task “plan next meeting” of Markus to another employee, i.e. if you change the ID of the user in this row for example from 20 (Markus) to 23 (Helmut ), the corresponding row will automatically be filtered out of the table view of Markus and added to the table view of Helmut.

Subsequent change of the user ID and consequent removal of the entry from the employee’s table.

If you want the task to be displayed not only to the user with the corresponding ID, but also to the creator of row , you can set two filter rules with an either-or link .

The alternative: the filter by the Creator column

In web forms , you can automatically capture the identity of logged in users. To do this, set {creator.id} or {creator.name} as the default value in the page settings of your web form and activate the option that this cannot be changed. Once you have made these settings, the ID of the logged-in user is automatically inserted in the web form and can no longer be entered or changed manually.

Definition of user ID as default value in web forms

Pin views