I am reaching out to the community to document and understand a significant workflow interruption we've encountered after a recent migration to 1Password Business. The core issue is that custom fields defined within item types (Login, Database, etc.) are not being populated by the "fill in browser" (Cmd+) shortcut or the inline browser suggestion dropdown. This creates a critical disconnect between the structured data storage and the primary method of accessing it.
Our team relies heavily on custom fields to store environment-specific connection parameters and API credentials that are not covered by the standard `username` and `password` fields. For example, a "Database" item might have the following custom fields, which are essential for our automation scripts and developer onboarding:
* `Host` (concealed)
* `Port` (text)
* `Connection String` (concealed)
* `Environment` (menu type with values: staging, production)
When using the fill command in the browser on a configuration page, only the standard `username` and `password` are offered. The custom field data remains inaccessible, forcing a manual switch to the desktop application to copy each value individually. This is a severe degradation of the user experience and a measurable productivity sink.
I have conducted a basic diagnostic to confirm the behavior is consistent:
1. Item Type: `Database`
2. Standard Fields: `username`, `password` — **work** with fill.
3. Custom Fields: `Host`, `Port` — **do not work** with fill.
4. Tested Browsers: Chrome and Firefox with the latest 1Password extension.
5. Desktop App: macOS, version 8.10.18.
The expectation is that the browser integration should be aware of all fields present in an item, or at least provide a configuration option to map custom fields to specific webpage inputs. The current implementation seems to only parse a hardcoded set of known field names.
Has anyone else architectured their credential storage around custom fields and encountered this limitation? Are there any known workarounds, such as using a specific naming convention for custom fields that the extension might recognize (e.g., `otp`, `secret_key`), or is this a fundamental constraint of the browser integration's design? I am particularly interested in whether this is a documented API limitation of the extension or if it's a feature gap that is being actively considered for development.
Data over dogma
This isn't just a workflow interruption, it's a major limitation of the 1Password browser integration's current design. The fill feature appears to be hard-coded to look for a very specific, limited set of field types.
I've observed the same constraint when trying to use custom fields for API key management. The data is there and secure, but the primary access layer, the browser, can't see it. It forces you into the app, which defeats the purpose of a quick fill command.
A potential workaround, though not ideal, is to abuse the `username` and `password` fields for non-standard logins. For a database item, you could put the host in the username field and the port in the password field, separated by a colon. It's messy and breaks the item's semantic structure, but it might get you through a browser form.
BenchMark