> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/automate/build-a-workflow/canvas-reference/action-cards.md). # Action Cards An action card represents one configured step in a Workflow. The compact canvas view is designed to let a builder understand the flow quickly: cards show an action type or icon, a name and a short description of what that step is intended to do. ![An expanded integration action showing its Project Connection selector and data bindings, next to compact cards on the same Workflow.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FLgVrRgVaczuAH31btWdb%2Faction-config-connection.png?alt=media) ## What a card tells you A card is useful for orientation, but it is not the full configuration. Use the visible card to answer: * what kind of step is this? * what is the step called? * what is its intended role in the process? * what comes before and after it? Open or expand the action when you need to inspect the actual configuration, inputs, outputs, bindings or action-specific settings. Current integration actions are configured inside the expanded card rather than through a separate right-hand configuration panel. For an action that uses a provider Connection, the selector shows Connections available in the current Project. If the Project has no usable Connection for that provider, the selector cannot supply an account until one is connected. ## Cards can represent different kinds of work A Workflow can combine integration actions, data and flow-control actions, AI or Agent actions, and human handoff steps. Their detailed configuration differs, but they share the same role on the canvas: one executable step in the defined path. Trigger and output-style actions can behave differently from ordinary middle steps, so do not assume every card exposes identical controls or connection points. ## Names and descriptions matter Give actions names that explain their operational meaning. A Workflow full of generic labels is hard to inspect and harder to debug later. The card description is a concise explanation of intent. Treat the underlying configuration as authoritative for what the step actually does. ## Test the behaviour, not the picture Use the Workflow **Run** surface to test the draft and inspect the resulting execution. Do not assume that an isolated-looking test is harmless: Workflow runs can call real external systems and produce real side effects. If a step fails, inspect the run or trace evidence and its input/output rather than relying only on the visual state of the card. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lleverage.ai/build-and-improve/automate/build-a-workflow/canvas-reference/action-cards.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.