> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alesta.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspace actions

> Understand Alesta's user-initiated, credit-consuming corrections and their protected execution states.

Workspace actions are bounded, user-initiated operations that update working context or create a new analysis revision. They are not background autonomy. You start each action from a visible control and can follow its status until it finishes.

## Actions surfaced in the Company workspace

Depending on the server catalog, plan, and target, the live workspace can offer:

* edit the company description;
* correct a generated document;
* add, remove, swap, or batch-edit competitors;
* improve an active signal with a correction;
* edit an eligible existing workspace file when that control is surfaced.

The server catalog defines the current title, description, required tier, availability, input type, duration class, and any limit. The interface does not infer plan access locally.

## Brief actions and decision actions

<Tabs>
  <Tab title="Brief actions">
    You describe what is wrong or what should change. Examples include editing a description, document, file, or signal. Be precise about the target and constraints.
  </Tab>

  <Tab title="Decision actions">
    The action is the decision itself and does not need a writing brief. Removing a competitor is an example. Confirm the target before starting.
  </Tab>
</Tabs>

## Execution model

<Steps>
  <Step title="Check access">
    The control reads the workspace action catalog. A locked action opens the plan dialog instead of submitting work.
  </Step>

  <Step title="Submit one intent">
    Alesta sends a durable request with an idempotency identity so a retry does not create a duplicate action.
  </Step>

  <Step title="Follow the active state">
    The action can be queued or running. Long-running competitor changes can take minutes because research and dependent documents may update.
  </Step>

  <Step title="Review the terminal result">
    A succeeded action refreshes the affected surface. Failed or rejected actions keep a reason that the interface can explain.
  </Step>
</Steps>

## Target locks

Only one action can run on the same protected target at a time.

* A document correction locks that document, not every document.
* A profile correction locks the relevant profile field.
* A set-level competitor change locks all competitor editing for the workspace until it finishes.
* An active signal correction locks that feed revision.

If Alesta reports that the target is busy, do not submit a second intent. Follow the existing status.

## Plans and credits

The free profiling run is zero-rated. Eligible paid workspace actions consume credits and require a plan that includes the action. A plan can include an action while the workspace lacks enough credits to start it.

The credit indicator and Billing page show the current allowance and use. See [Credits](/credits) for details.

## Human-control boundary

Most workspace actions change Alesta's own working context. Signals can also expose a separate external action, such as creating a GitHub issue. External writes require their own review and confirmation flow.

An action completing in Alesta does not imply that a website, social network, email system, or advertising account changed.

## References

* [Availability, plans, and access](/concepts/availability-plans-and-access)
* [Credits](/credits)
* [Signals](/workspace/signals)
* [Locked and unavailable actions](/troubleshooting/locked-and-unavailable-actions)