In mid-2023, DeepSource started getting a huge influx of support requests pertaining to controlling their accounts ⎯ both for Team and Personal accounts. Deleting a team or personal account, for example, was a pain in the arse. While manually deleting accounts based on support requests worked for a while, it got overwhelming after a point, especially dealing with users who had just signed up to check out the product and now wanted out.

We had to delete the accounts as requested to keep up with compliance requirements, especially for accounts from the EU region.

As we kept talking to our users and going through the pretty huge volume of incoming support requests to manage team and personal accounts, we came across a bunch of recurring themes ⎯ and interestingly, there was a pretty huge overlap with what our enterprise customers were also asking for. We sat down and mapped the pain points to actionable user stories. Some of these went out as standalone updates while chunks of this were also part of The Mimir update.

<aside> 🛠

Note that all of these features were developed separately but all of them originated from the deluge of support requests and customer pain points ⎯ all connected to the common theme of having issues with controlling their Team and Personal accounts.

</aside>

User stories

• Allow users to add seats before adding collaborators ⎯ We had 3 role permissions in DeepSource -

  • Administrator : They have full access to all repositories and the team, including billing, adding and removing members.
  • Member : They have the ability to add and edit specific repositories.
  • Contributor : They can only view the issues and metrics on public repositories, but won't be able to take any actions on issues. They would need additional access to individual private repositories from the repository's settings. Useful for onboarding contractors/freelancers.

  Among these, Administrator and Member roles are counted to give the total number of seats in a team account in DeepSource. Contributors have limited and mostly view-only access and are hence not counted against seat numbers. Issues started cropping up when teams exhausted their seats and all subsequent invitees got added as Contributors instead of Members. We solved this by giving users an explicit CTA to increase the number of seats ⎯ both on the Billing page as well as the Team Members page.

  Billing page prototype 👇

  Export-1732806925359.mp4

Team Members page

• Allow users to change roles for existing team members ⎯ Earlier, we did not allow roles to be changed for individuals who joined the team with a pre-defined role. For example, if I sent someone an invite link after setting their role as Member, there was no way for users to upgrade them to Administrator without removing them from the team and then adding them back again with the updated role.

  Export-1732808768416.mp4

• Allow users to monitor pending invites ⎯ Allowing users to look at pending invites was a small quality-of-life improvement that we shipped, along with the ability to Send a reminder or Cancel the invite.

  

• Inform users when they are the sole admins ⎯ There were often issues with team recovery and deletion in the scenarios where the team only has one admin : so when the admin’s account becomes inaccessible for some reason (it could be them forgetting the password of their GitHub/GitLab/Bitbucket account), they effectively lose access to their DeepSource accounts as well, as the DeepSource account is always tied to a VCS provider.

We started showing an info banner to the users to add more administrators to improve the team’s Bus factor.

![image.png](<https://prod-files-secure.s3.us-west-2.amazonaws.com/acaef6d6-6235-4014-a5cc-350a1535ee62/e430b62c-a08f-4200-8df8-0b5bf42633c6/image.png>)

• Access Control refinements ⎯ Since all team and personal accounts on DeepSource were connected to a VCS provider, our users had to face a bunch of conflicts while dealing with repositories that had contributors who were not part of the organization on the VCS provider to which the repository belonged. And often while syncing access controls from the VCS provider, it became unclear that who was getting added to the team on DeepSource vs who was getting added because they were added in the VCS provider.

This issue became even more pertinent for teams who maintained open-source projects and also had private repositories. We adopted a three-fold approach to solve this confusion - - We added a label against every team member and repository collaborators to show where they were coming from ⎯ viz. whether they were getting added through the VCS provider OR whether they were getting added through the DeepSource dashboard.

    ![image.png](<https://prod-files-secure.s3.us-west-2.amazonaws.com/acaef6d6-6235-4014-a5cc-350a1535ee62/930a3d51-fc74-43af-994b-adde0c53691d/image.png>)
    

- We allowed users to Manually sync the access control with their VCS provider to account for manual intervention in the case of automated sync discrepancies (maybe due to API rate limits, or service degradation) ⎯ after explicitly informing them that the changes synced from their VCS provider would override the changes made on DeepSource.
    
    [Export-1732824281391.mp4](<https://prod-files-secure.s3.us-west-2.amazonaws.com/acaef6d6-6235-4014-a5cc-350a1535ee62/1ea16af7-aefa-4d1b-9e4f-57328de6ce24/Export-1732824281391.mp4>)
    

- Additionally, we removed the ability to directly add a collaborator to a repository. Unless the user was already part of the team or added to the repository via the VCS provider, the administrator needed to manually add them to the team before adding them to a repository.
    
    [Export-1732824862748.mp4](<https://prod-files-secure.s3.us-west-2.amazonaws.com/acaef6d6-6235-4014-a5cc-350a1535ee62/e22778aa-d302-49ae-a578-a1e03131a149/Export-1732824862748.mp4>)