Introducing team settings — how I planned a multiple users feature

William Bengtsson
Mar 17 · 4 min read

“You’ve never heard the phrase: “Divided We Stand”
― Manuel Corazzari

Well, for our new feature at Tink, I’d use that quote he’s quoting. As in, we’re building team settings, so multiple accounts can access one organization, compared to solution today where all users have to login with the same account. So, we’re dividing an account to multiple users to make it more efficient and secure for the organization as a whole. Example: previously, three users shared one account to access one organization. With the update, three users create one account each to access the organization. Making it more secure, easier to handle and more efficient.

Three users accessing an organization through one account compared to three users accessing an organization through three acc
Three users accessing an organization through one account compared to three users accessing an organization through three acc
Three users accessing an organization through one account — compared to three users accessing an organization through three accounts separately.

What is Tink

First, a quick introduction. I design the product at Tink. It’s a platform that provides banks, financial businesses and developers across Europe with new possibilities to access bank data. With our API, one can fetch customer’s account information, identity, mortgages, account balance, transactions, and much more (with consent from customer, of course). To showcase the products we provide, we’ve built an app where one can connect all (!) their banks and debit / credit cards and get an overview of how they spend their money — and possibly predict their future spending.

With that said.

Introducing team settings

To build with our API, you’ll need to sign up to our console. From there, you get the usual stuff to start configuring with our API; client-secret, setting up redirect URI’s, configuring markets, banks, etc.

And now, you also have the ability to manage an organization; inviting users, handling multiple organizations, setting roles and more, to make Tink compatible with larger companies who need more detailed role assignments with different rights.

Why the feature was needed

Only one user for multiple people from one company

Customers use one sign-in for one account, and need to share it. That came with security issues and complicated to share their password etc.

Some users have more rights than preferred

A user might only need to view usage reports, but will still be able to access client-secret and other confidential information, making it difficult to share the account to all people within the organization.


To solve this, we needed three things in order: team settings page, team switcher bar and roles.

Team settings page

  • We needed a new page, Team settings, where one could configure roles, invite and remove colleagues.
  • The admin would create a regular account like everyone else, but when they invite the first person, they’d be converting that user to a team profile.
  • On the Team settings page, the admin can invite multiple new users at once, selecting their respective roles to make it as easy as possible to set up a new organization.
  • There would also be another tab where the user roles are described somewhat, for reference, if an admin is unsure about what different roles would be entitled to do.

Team switcher bar

  • They’d get a new bar in the bottom left corner where they can switch over from their personal account, to the team account. When switched, the interface would display the team apps. The user could switch back to their personal (or other team account if they’d have multiple) and the interface would switch over to that user.

Introducing roles

We needed different roles, because not all invited would need rights to create new apps, access important, security-heavy things like the client-secret, so we solved this issue by creating four new roles that can be configured by an admin in the Team settings page. Roles would be:

  1. An admin would have full rights; manage users, configure apps, access invoices, view usage reports, and more.
  2. A developer would have access to all the products and be able to configure each of them, as well as configuring apps.
  3. A visitor would only be able to see, and not configure. This could be for new colleagues. Or a data analyst who might only need to see usage reports and the statistics of how the app was being used by their end-customers.
  4. A billing manager would mainly use it to access usage reports, and see how much they’d use our product, as well as to see and download invoices.

That’s it for now, feature will keep on evolving.

Feel free to check out my portfolio at

William Bengtsson

Written by

Product Designer at Tink in Stockholm. Previously Lead designer for proptech startup, Plentific. Hyper Island: Interactive Art director alumni. Football addict.

More From Medium

More from William Bengtsson

Also tagged Product Design

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade