Floating Window Buttons

Type: Explanation | Audience: Interface builder user | Goal: Understand what a floating window button is, why its views get no Pipedrive record, and what you can still build with one

What a floating window button is

A OneClick button sits on one of two places in Pipedrive. Most buttons sit in the main panel of a deal, a person or an organization — the user opens a record, and the button belongs to that record. A floating window button sits somewhere else: it opens a draggable, resizable window that floats over Pipedrive and stays open while the user navigates around the app. It can be opened from the apps dock, from a phone number, from the call tab, or from another app through the SDK.

A floating window is not a modal and it is not an interface of its own. It is the surface the button lives on, exactly as the main panel is. Pressing the button opens your interface in a modal the same way a panel button does, the views render the same way, and navigation between views works the same way. Everything about building a view is the same except for one thing: the data a Pipedrive record would have given you.

Why there is no Pipedrive record

A floating window is global. It is reachable from anywhere in Pipedrive and it survives navigation, so it cannot belong to a record — the record the user was looking at when they opened it may already be a different one, or none at all. Pipedrive gives the window only the signed-in user, the company, a token and the button's own id.

For a view this means the record is not merely empty, it never arrives. A panel button's run always names one record: the user opened a deal, a person or an organization, and the button knows which. A floating window button's run names none.

How the builder tells you

Open the views listing of a floating window button and two things are there that a panel button does not show. Next to the button's name is a grey badge reading ⧉ Floating window — a permanent mark of which kind of button you are editing. Under the Beta box is a grey row headed No Pipedrive record, which spells out the consequence: this button floats over Pipedrive and opens from anywhere, so its views get no data from a deal, person or organization.

Both are neutral grey and carry no warning icon. A floating window button is not broken and there is nothing to repair — the row is a fact about the data, not an error.

What the builder hides

Rather than let you pick a value that would always resolve empty, the builder removes those values from view:

Where	What is hidden
Data Picker tab strip	The Deal, Organization and Person tabs.
Data Picker Context tab	The System context values resource_id and resource.
Preview and Test	The Pipedrive resource selector in the toolbar.

The hidden tabs are gone from the strip, not greyed out, and the picker opens on a tab that is actually there. If a saved view already holds a chip from a hidden tab, the chip still renders under its own name rather than as an unknown reference — hiding a tab never rewrites what you have already built.

In Test, the run does not ask Pipedrive for record data at all, because there is no record to ask about. Your external data source is still called exactly as it is for a panel button. In Preview, the view renders against the saved Sample data as always.

What you can still build

Everything that does not depend on the record stays:

• The view's external data source. It is called the same way, and every field it returns is available under *. This is the main way a floating window view gets its content.
• The signed-in user. The User tab resolves from the session, not from a selected record.
• Search params, variables, functions and loop items — none of them read a record.
• company_id and user_id on the Context tab, both read from the session token.
• View references on the Context tab, which point at the other views of the same button.

In practice a floating window view can do nearly anything a panel view can. It reads its data from your endpoint and from the signed-in user instead of from a Pipedrive record. Forms submit normally, tables render normally, and navigation between the button's views works normally.

What your endpoint receives

A run without a record carries that fact honestly: the two record values are never faked with 0 or an empty string. How the absence looks on the wire depends on the transport, because JSON can carry null and the other two shapes cannot:

Transport	resource and resource_id on a floating window run
JSON body ({ data, meta })	Both keys are present with the value null, so the payload shape stays constant.
Multipart form data (meta_* parts)	Both parts are missing entirely.
GET data source (x-oc-meta-* headers)	Both headers are missing entirely.

The other five metadata values — button_id, company_id, event_id, interface_view_id and user_id — are sent on every run, floating window or not. A panel button's payload is unchanged in every shape, so an integration that already works keeps working.

Full payloads for both cases are in Form Submission Types and View Data Source.