Showcase: How we use tags and custom fields for better search

This is a solid approach, especially the distinction between tags for access and fields for data. One caveat we've found is tag sprawl. It's easy for teams to start creating unique tags like `#vendor-payment-clientname` which defeats the purpose of broad categories. We had to establish a simple controlled vocabulary to prevent that.

Your point about searches for renewals is key. Do you have a process for regularly running that search, or is it more of an ad-hoc check for your team? Setting a calendar reminder to do those filtered searches quarterly has been a game-changer for us.

Tag sprawl is such a real danger! We hit that wall about a year in. Our "solution" was embarrassingly low-tech: we created a single read-only note in our main vault called "The Tag Bible" that lists every approved tag and a one-line description of when to use it. New folks can't create items until they read it.

For the renewal searches, we've automated them a bit. We use Zapier to watch a specific saved search for items with a date in the next 60 days, and it drops the results into a dedicated Slack channel every Monday. It's not perfect, but it surfaces those critical items without anyone having to remember to check.

The search trick is neat until you have 5,000 items and realize your custom date fields are a free-text mess. Good luck searching for "Contract Renewal Date (YYYY-MM-DD)" when half your team entered "Jan 15".

Automated searches break when your field naming isn't enforced by the tool itself. You're now paying for Zapier to parse bad data.

>Tags define 'who' and 'what'.

This clicks for me. I've been using tags as extra search keywords, but that just makes a mess. The idea of using them for access like `#team-it` is way smarter.

Do you ever run into problems where a login needs to be seen by two teams? Do you add both tags, or is there a better way to handle that?

You're not wrong about the core idea, but you're skipping past the operational cost. Tags for access control sound great until you have to reconcile them across a dozen teams after the next re-org. Who audits that `#team-it` tag is still accurate six months later when half that team has moved to platform engineering?

And those custom fields for dates are a ticking time bomb without schema enforcement. You're one typo in "Contract Renewal Date (YYYY-MM-DD)" away from your fancy 90-day search returning nothing. The tool doesn't care if someone enters "Q1-2025". Now your proactive system is just another data swamp you have to maintain.

That makes a ton of sense, framing tags for access and fields for data. I've been letting my team just tag by project name, which already feels messy.

A practical question about the custom fields: you mentioned `Support PIN`. Is that field visible anywhere when you're using the browser extension to autofill a login, or do you always have to open the full item to see it? Trying to figure out if it helps in daily use or just for audits.

Great question, I was wondering the same thing! In my experience with 1Password, you have to open the full item to see custom fields like a PIN. The browser extension usually just autofills the main username and password fields.

It's definitely more for audits or those planned support calls. Not super handy for daily logins, but crucial when you need that one extra detail.

Has anyone found a password manager that does surface custom fields in the quick-fill view?

That's the fastest way to bloat your tag count. Now you're tagging with `#team-it`, `#team-finance`, `#team-marketing`, `#team-ops`.

We tried that. The audit cost when a team rebrands or merges is a nightmare. Create a shared vault for that one credential instead. Tags should be for the *primary* owner/context, not an access control list.

Your approach of separating concerns between tags for access and fields for data is architecturally sound, but your example of using `#team-marketing` as a tag for access control is the point where it becomes operationally brittle. Tag-based access control conflates metadata with permissions, which violates the principle of least surprise in system design. When a credential needs to be accessible to multiple teams, you're forced to either pollute the tag namespace with multiple team tags, as user400 noted, or create a new, composite tag like `#shared-it-finance`, which immediately leads to the vocabulary sprawl others mentioned.

A more sustainable pattern is to use the vault structure itself as the primary access boundary - credentials shared by Marketing reside in the Marketing vault. Tags within that vault can then be purely descriptive (e.g., `#vendor-payment`, `#onboarding`) for internal categorization, without carrying the burden of permissions. This delegates access audits to the vault membership layer, which is typically easier to manage and audit directly than reviewing thousands of tagged items post-reorg. The search capability remains; you would search within the Marketing vault for items tagged `#vendor-payment` with a renewal date in the next 90 days. It adds one step to the search but removes a significant maintenance liability.

Great foundational post. You've hit on the real goal: making things findable *before* the panic search.

I've seen this system work well, but it hinges on what a few others have mentioned: discipline. The moment someone creates a `#team-marketing-ops-special-project` tag instead of making a shared vault, the whole taxonomy starts to crack. That's not a flaw in your rule, but it's the human factor that often gets overlooked.

The custom fields for dates are powerful, but do you have a process to keep that data clean? Without it, those proactive searches can give a false sense of security.

You've correctly identified the core separation of concerns for metadata, which is crucial for any scalable system. I agree that using tags for broad access context and custom fields for structured data is a strong foundational model.

However, your example of using `#team-it` for access control introduces significant long term maintenance overhead that the model doesn't address. Access permissions should be a function of vault membership, not tags. Tags are ephemeral metadata, while vault structure provides a durable, auditable permission boundary. When you use a tag for access, you're creating a parallel, unsynchronized permission system that will inevitably drift from organizational reality after a restructuring, creating security and compliance blind spots.

The power of your custom field searches, like for contract renewal dates, is also predicated on strict data governance you haven't described. A field titled `Contract Renewal Date (YYYY-MM-DD)` has zero enforcement. Without a validation layer or a dedicated date-type custom field, you're relying on user discipline, which is not a scalable control. How do you prevent, or at least monitor for, entries like "Next Quarter" or "01/2025" that will break your 90-day search?

You're right about the permission drift, but you're underestimating the overhead of vault-based access for ephemeral projects. In a 500-person org, a formal vault request process can take weeks. We use `#team-it` as a *discovery* tag, not the final permission. It lets the team lead find what they need to request access to, and our monthly IAM review script compares tag presence against actual vault membership to flag discrepancies.

The data governance point is where I fully agree. Our solution was to abandon free-text date fields entirely. We created a dedicated "Contract" item type with a proper date picker field. If your tool doesn't support custom types, you're fighting a losing battle. Enforcing "YYYY-MM-DD" in a text field is a compliance fairy tale.

You lost me at "tags are for access control." That's a fast track to credential sprawl.

Those complex searches you're so proud of? They're completely dependent on flawless data entry for those custom fields. You've traded "messy" for "fragile." One person entering "2025-01-15" while another puts "Jan 15" and your elegant 90-day search is just performance art. You've built a system that assumes perfection, and that's a dangerous assumption to make.

Your distinction between tags and custom fields is a really helpful mental model for keeping things organized. It's the proactive approach that often gets missed.

I've found the true value emerges during handoffs, like when someone leaves a team. Searching for `#team-marketing` to review access is efficient, but it only works if the tagging is consistently applied to *every* relevant item from day one. That's where a simple team checklist for new credential entries can save a lot of retroactive cleanup later.

Your point about complex searches for renewals is spot on, though it does rely on that date field being used reliably. How do you handle reminders or workflows from those search results? Do you export them to a calendar, or is there a way to act on them within the password manager itself?