Hey Alex,

The value that is returned by tsf_user() should be the same value as the user's User id in IAM. So if you would add the value of this User id to the driver table, this would allow you to filter the data selection based on the user that is currently logged in. This can be achieved by using the tsf_user() in your prefilter query, for example.

Does this help?

Hi Renée,
I presume that this user ID can be found in a table within the IAM database, is that correct? So far, e haven't been able to find anything in any IAM table. We see a name as user ID, not a GUID. So, the GUID we see in the application can't be traced to an IAM user (now that I'm typing this my brain gets misty as well ). We need to be able to automate the linking of IAM users with the driver role to the users in the application driver table. There's hundreds, possibly thousands of drivers to link. No way someone will go into IAM to copy a GUID, go back to the application, find the driver and update an ID field with that GUID, one by one.
Best regards,
- Alex.

Hey,

In my case the field usr_id holds my actual username, the same username that is assigned to my user at the database/server level. So in the case of Thinkwise employees this is something like thinkwisedomain\myname.

Could you maybe share a screenshot of what your IAM user looks like at the database level? If you don't want to share sensitive data, you can also just create a dummy user and show what that looks like. Maybe that will help me to better understand what you mean

But in any case, if you want to create automatic linking between IAM users and the driver table in your end product you can try to build your own interface between IAM and your end product. However you would still need something recognizable at both levels to base the interface on, i.e. to create the link between both applications. This can also be the first name and the surname if that works for you guys, but I can't judge that.

Hi Renée.
We found the solution by digging into the tsf_user() function. We can simply call system_user from within our application to get the user name. And in IAM, the username is also available. This is great! We don't have a proper context without impersonating every IAM user, so we would never be able to generate the user GUID as returned by tsf_user. But system_user works!
Thanks for your effort, Renée
Best regards,

- Alex.

Hi Alex,

I’m assuming you use an Azure DB. Those tend to have CONTEXT_INFO filled with a guid by default when connecting from SSMS / Agent jobs for some reason.

The database system_user will return the actual connection user. Which is fine for direct connections using SSMS.

However, when accessing the application via a Thinkwise GUI or Indicium, the CONTEXT_INFO will be overwritten by every runtime component of the Thinkwise platform with the correct user - tsf_user() will work as intended and return the user ID as shown in IAM.

It is important to use tsf_user() in most scenarios because system_user will be the connection pool user used by Indicium or the Web GUI at this point, not the IAM user ID of the end-user.

More info here.