@ink.dude in your use-case, you’re creating a first time login for users and sharing it via Bitwarden?
Once the user updates their password (assuming they create a new password after the temporary one you’ve generated) - that’s where you’d like the un-share ability?
I invite user to organization through e-mail. Of course user create password yourself.
After that for example i want to share this user some passwords(dropbox,gitlab etc.). What shoud i do? I create collection (for example named as this new user) in which add this user and share passwords to named collection. When user fired, what should i do? revoke shared passwords from named collection (not transfer this passwords to common collection or something) i want just revoke passwords and after that delete the collection.
Administrating bitwarden shared passwords is very difficult
I buy org licence, pay 10$ but for what? I don’t know.
I check passbolt for that issue and it’s ok. in passbolt you just add users through e-mail and simply share password what is you want. And it’s just working good. When you click on password you see for what users (or groups) you share this password and of course you may revoke passwords from share
and passbolt don’t use any collections - it’s don’t needed
and all this for free works perfectly
@ink.dude - good question. The idea behind collections is to create collections that are shared/mapped between different groups of people. For instance, you may have passwords that the entire operations department needs.
Those credentials would be in an Operations collection, and that collection assigned to an Operations group, containing Operations users. When a user is removed from the Operations group (fired, change jobs, etc) - they no longer have access to that collection or its credentials.
You can assign a user to one or many groups, depending on how granular you wish the control to be.
@tgreer
I told you about private passwords for each user which i want to share to him and only him. I need to create 50 collections (if in my org 50 users)?
And main question, do you create button which is revoke password from collection and come back in my personal vault?
It’s very important to me and many other people who wants to use bitwarden
i very frustrating when i see triangle sign with my passwords and i can’t revoke password from collections, i don’t have any time to search in which collections my password stuck or something
I afraid you nothing to do with this issue :(((
@ink.dude - that’s correct, currently if you had passwords that needed to be shared with 50 individual users, you’d need 50 collections.
With the enterprise plan you can assign those users to individual groups as well, and removing them from that group would in face “un-share” the vault item(s).
I do want to better understand the use-case with sharing items with single users vs. those users managing that credential on their own. Again, just trying to understand better, not discrediting the use-case.
@tgreer actualy we talks with you in thread in which many users discuss about this issue about two years.
I just want to know read this thread any developers from Bitwarden? What he is think about this issue?
I want to say about revoking shared passwords from users without deleting this users. Why revoked password should be putted in another collection instead my private vault? I owner of this password and i want to become this password in my private vault after the unshare from collection. Why i can’t revoke shared password from organization to my personal vault?
I unfortunately ran into a flaw of export vault on web vault. I shared all my items to an organization but then wanted to unshare them. There is no unshare option so I went to my vault and exported to .json then purged my organization. The flaw is that the export vault .json file was empty except for the metadata for folders (reminder i exported my vault from my vault page, and purged my organization from my organization page). Therefore my vault lost!!
Yes I should have checked the .json file to be sure, but I was operating under what I thought was careful measures. I luckily had a backup from a week ago, but I lost 10+ passwords!
I tested this by doing it again in the same process of steps laid out above. .json file was empty again.
Feature requests: 1) Unshare Option and 2) to be able to export vault items from your vault page even if they are shared to an organization, or 3) at least have better warning of exporting shared items or better confirmation of number of items exported. (currently the only communication about shared items I could find was “they will be owned by the organization”, but its frustrating that they still appear in my vault giving the impression that the export vault tool will still work within ‘my vault’)
@tanner - thanks for the feedback here. While this is how the export was designed to work, I understand it may not have been clear that only personal vault items would be exported.
Is there any new information on an “Unshare”, “Reclaim”, or another sharing option and could we get a decision on whether it will be added?
I have happily been using BitWarden but have just realized that being unable to transfer ownership to another organization/user simply won’t work for my use case anymore. I’m going to have to move back to LastPass manually if this isn’t on the todo list. LastPass has a way to just straight up share a password between multiple people, then revoke access at a later date.
I have two people whose accounts I create and maintain, note that I do Not own the accounts. Currently the only solution is to have them each share their only free organization with myself, then move all their passwords into the organization. However, if at any time in the future they wish to revoke access from me they cannot move the passwords out of the organization they own. This also creates a problem if those two want to share a password betwixt each other. They would Both have to pay for a premium organization just to share a password between each other. Also, if I make a password and put it in my organization, then at a later date I wish to give it to a new Bitwarden account’s organization I cannot without recreating it.
more reason to implement real sharing. it seems the devs of bitwarden are so enamored with the idea of orgs and collections to implement sharing that you refuse to admit how big a problem it is creating for users that want to share. as a ux professional this boggles my mind. i understand that implementing this feature as it should be to allow for users to use it the way they want would be a large effort, and i do not think anyone would scoff if they understood how much effort it would take. but you dug yourself into this hole and the thing you built with the excavated earth is not what users want. this community probably represents a small fraction of the bitwarden userbase. so if there are people here saying they are not using bitwarden because this feature does not exist, there must be so many more people that are not signing up to post in this community that are not getting bitwarden subscriptions because of the lack of real sharing in bitwarden.
what is the reason that a user would have to create individual collections to share individual credentials? why is that middle layer necessary? what is it doing that is so necessary that bitwarden cannot be done without it? if it is completely necessary and there is absolutely no other way to implement sharing, why can you not abstract that enough to render it functionally invisible to the user? change a user account into a functional organization and they can create a shared “folder” that is functionally on the backend a collection and they can invite another user to allow access to that “folder” and the credentials inside it? that does not change the hierarchy you have in place, but it presents it to the user in a more acceptable manner.
i am frustrated about this, because the stance of the developers seems to be “we cannot change the thing we made to work the way users want it to because we already made it. so the users need to change how they want it to work.”
at the very least implement a way for the collection/organization owner to move it out of the organization and back into their personal vault without having to manually duplicate the item.
as @FergusMacdonald said this should not be a one way system.
@straef - you make valid points. It is important to note that it works this way currently with a focus on workplace teams and enterprises whose sharing needs more align with groups of users needing access to sets/collections of credentials.
We recognize there are other approaches to sharing and will continue to explore, evaluate, and add when we can. All feedback in this forum is much appreciated and is indeed considered when making changes.
And, as a UX professional I’m sure you feel our pain, as it’s somewhat reminiscent of a quote from the late comic Mitch Hedberg:
Y’know, you can’t please all the people all the time… and last night, all those people were at my show.
The Bitwarden team is listening (well, reading)!
@tgreer Wouldn’t the suggestion which was made multiple times in this thread be a great immediate improvement without the need to implement a much more complex sharing capability (which of course would still be great in the far future)?
Since organization owners can already delete passwords in shared collections for all users… why not provide an additional option to “unshare” an item that puts the concerning item into the owners personal vault?
@wolfi - Can you specify which solution exactly? I want to be sure we’re speaking of the same resolution.
The clone feature is available to Org admins and above, so “un-sharing” can be achieved by cloning an item (and not sharing it) and deleting the shared item.
You say it as if unsharing by moving an item from an organization back to an Admin or Owner is equivalently or less privileged than deleting an item. Whilst this is true on a technical level, it’s not on a social level (and password management is as much about the social as the technical).
If this functionality was implemented, then Admins/Owners would unshare items and then carry on using them as personal credentials. But of course, once credentials have been shared to an organization, you have to assume that anybody in the organization could have access to them. This is dangerous. Whereas deleting an item has a completely different use case - it’s for when an item is null, void, no longer needed. If the account for the deleted item remains, then it is self-evident that the credentials must be changed before the item is deleted. But for unsharing, this is not the case and would cause issues.
For some people and organizations, the way that Bitwarden handles this is preferable. For others, it is not. The only way that Bitwarden will accommodate both viewpoints is with a deeper toolset of enforcement policies and access controls that enables both workflows to be achieved.
But guess what, at this point it becomes another CyberArk or Password Manager Pro. Is this what Bitwarden is supposed to be? Enterprise bloatware with a gazillion options to configure before you can even get started? I don’t think so.
@d.b Geat reply! Thank you for taking the time lay it out for me in this depth. I was totally only thinking about the technical implications. But you are absolutely right about the social context. You changed my mind.
@tgreer I was exactly thinking of a shortcut for the clone & delete routine. But @d.b has definitely changed my mind on unsharing in general. Just does not make sense in a password manager.
I disagree on the above. I don’t see any difference from social context.
In both cases, it is self-evident that collection credentials are “public/shared” and if you want to move it back to your own “private” vault or to delete simply it from the “public/shared” collection, then you should change the already “public/shared” password. In fact, if you allow items to be copied/duplicated from collections to private vault, it’s even clearer to the end user that anyone can do this.
I’m not clear how, by forcing users to manually copy the credentials then deleting them from the collection, will help with social level usage of the application. I personally think that a popup/warning when migrating or deleting items from public collection to private vault would make it even more evident to the end user.
At a more fundamental level, I disagree with the intentional crippling of the export/copy of the collection. This gives a false sense of security and does nothing to improve security and results in unnecessary hindrance to the end user experience all in the name of security. Once transferred to the collection, the information should be treated as public information, to the extent of the users of the collection, and hence users should just treat the information as such accordingly. i.e. when you transfer a password from collection to private, its just like getting a preassigned pin from your bank, you change it the first opportunity you get.
You must have a lot more trust in your users than I do, because I tend to work under the assumption that users are quite unintelligent, and this certainly would not be self-evident to such a user.
But in fairness, this is something that is also dependent on environment - different organisations will have different types of employees, and some will be more versed in security best practices than others. Which is why I said this behavior will be desirable to some, and undesirable to others.
Is this why Bitwarden are doing it though? I provided my own reasoning, but the official word from Bitwarden (further up this thread) does not cite an increase in security. It seems their argument is more that the logistics are too messy to implement (which I don’t agree with).
Hey folks - there are a couple of items going on in this thread:
We handle sharing the way we do currently (from a UI/UX standpoint) with a leaning towards enterprise-group-usage moreso than many individual user-user shares
In regard to product functions, the guise of “un-sharing” can be had by doing one of 2 things:
Hopefully this answers more questions than it creates 
Taking already shared credentials from an organization and placing them into a private vault essentially implies them to have been compromised—as far as private utility is concerned—even if it’s sometimes only a theoretical risk. This is the “data can’t be truly unshared” issue.
To help solve that, after “unsharing”, these credentials could be visually “attention needed” flagged as being compromised, as a reminder and means of tracking whether they’ve yet been changed.
Each unshared item could have a single flag, or Bitwarden could specifically and granularly track the last change date of their secrets (passwords, TOTP keys and hidden fields). Unflagging can also either be manual, or automatic after changing the relevant values.
(I posted a much more extensive, organization-vault version of such flagging in another feature request, but you don’t have to go there for details relevant to personal-vault unshare flagging.)