Summary
The only data sources are pipefy_pipe and pipefy_phase, both keyed by id. A config that manages resources inside an existing org has to hardcode ids it cannot look up.
Proposed data sources
pipefy_organization: wrap organization(id:), exposing name and the lists of pipes and tables (id and name). Enough to reference an org and discover what is in it.
- pipe lookup by name: there is no server-side name filter on the organization's pipes, so this is a client-side match over
organization { pipes { id name } }. Either fold it into pipefy_organization outputs or add a pipefy_pipes data source with a name filter.
pipefy_phase_fields (or extend the pipefy_phase data source): list a phase's fields with id, uuid, label, type. Automations and field conditions reference fields by id, and today there is no way to get those ids without leaving Terraform.
Notes
The client (internal/provider/client/api_client.go) has no pagination support. Organizations with many pipes or tables will need cursor handling on these list queries.
Summary
The only data sources are
pipefy_pipeandpipefy_phase, both keyed by id. A config that manages resources inside an existing org has to hardcode ids it cannot look up.Proposed data sources
pipefy_organization: wraporganization(id:), exposingnameand the lists of pipes and tables (id and name). Enough to reference an org and discover what is in it.organization { pipes { id name } }. Either fold it intopipefy_organizationoutputs or add apipefy_pipesdata source with anamefilter.pipefy_phase_fields(or extend thepipefy_phasedata source): list a phase's fields withid,uuid,label,type. Automations and field conditions reference fields by id, and today there is no way to get those ids without leaving Terraform.Notes
The client (
internal/provider/client/api_client.go) has no pagination support. Organizations with many pipes or tables will need cursor handling on these list queries.