> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/issueops/issueops.md).

# IssueOps

IssueOps is how you operate codev from your source control — GitHub or Azure DevOps — without opening the codev app. You either file a request from the **Operations** catalogue, or comment a command on a pull request or issue. codev turns each one into a tracked work item, runs the matching flow, and posts the result back to the thread.

There are two ways in:

* **The Operations catalogue** — a menu of ready-made requests (create a sandbox, request elevated access, install a package, run tests). Each opens an issue in your repository and starts the flow that carries it out.
* **Comment commands** — type a command on a pull request or issue (for example `/sfp sync qa` or `/sfp approve`) and codev acts on it in place.

Both paths require the requester to be a codev member; actions that change a shared environment or approve a release require the **owner** role. Everything works the same on GitHub and Azure DevOps.

## The Operations catalogue

<figure><img src="/files/8Dv7jVt92adyZqqFRV1M" alt="The Operations catalogue"><figcaption><p>The Operations catalogue, grouped by Access, Package, Environment, and Test</p></figcaption></figure>

The **Ops** section lists the operations codev can run, grouped by area:

* **Access** — request elevated privileges in production, or freeze and unfreeze users in an environment.
* **Package** — install an sfp artifact, or a managed or unlocked package, into a target org.
* **Environment** — create, refresh, or delete a Salesforce sandbox, or sync an org to a branch.
* **Test** — run Apex tests against an org.

Clicking **Create** opens a short form for the operation's parameters. When you submit it, codev opens an issue (a work item on Azure DevOps) in your repository describing the request and starts the flow that carries it out. The issue is the record of the request: codev comments on it as the flow progresses and closes it when the work is done.

## Tracking requests

**Request Tracking** lists every request and where it is. A request moves through **open → in progress → completed** (or **failed**), and you can filter by project, status, type, who created it, and time range. Each row links back to the issue it came from and, once running, to the flow carrying it out — so you can answer "did my sandbox refresh finish?" without leaving codev.

## Comment commands

You can also drive codev by commenting on a pull request or issue. Commands start with `/sfp`, `/codev`, or `/sfops` (the leading `/` is optional, and the three prefixes are interchangeable), and codev replies in the thread.

Most commands act on the **review environment** assigned to a pull request:

| Command                        | What it does                                                              |
| ------------------------------ | ------------------------------------------------------------------------- |
| `/sfp assign`                  | Assign a review environment from a pool to this pull request              |
| `/sfp status`                  | Show the assigned environment, its expiry, and a login URL                |
| `/sfp extend --hours 24`       | Extend the environment's lease (or `--immortal` to stop it expiring)      |
| `/sfp renew`                   | Release the current environment and assign a fresh one                    |
| `/sfp unassign`                | Return the environment to the pool                                        |
| `/sfp sync <env>`              | Deploy the pull request's changes to a named environment (approval-gated) |
| `/sfp sync-review-env`         | Deploy the changes to the assigned review environment (no approval)       |
| `/sfp record` / `/sfp stop`    | Start or stop a browser recording session on the review environment       |
| `/sfp approve` / `/sfp reject` | Approve or reject a pending request (see [Approvals](#approvals))         |

Add `--domain <name>` to scope a command to one domain. `/sfp help` lists the commands available on the current thread. Only codev members can run commands, and actions that change a shared environment or approve a release require the owner role.

## Approvals

Some operations — releasing to a production environment, or a privileged-access request — pause at an approval gate and wait for a person. Approvers can resolve them from [Pending Approvals](/flxbl/codev/flows/overview.md#pending-approvals) in the codev app, or directly in the thread:

```
/sfp approve
/sfp reject --reason "Change freeze until Monday"
```

Approving or rejecting requires the owner role. See [Flows: Pending Approvals](/flxbl/codev/flows/overview.md#pending-approvals) for segregation of duties and the audit trail.

## GitHub and Azure DevOps

IssueOps works the same on both providers. On GitHub a request is an **issue** and commands run on issue and pull-request comments; on Azure DevOps a request is a **work item** and commands run on work-item and pull-request comments. The set of operations and commands is identical.

## Related

* [Flows: track runs and approvals](/flxbl/codev/flows/overview.md)
* [Syncing Environments](/flxbl/codev/ci-cd/sync.md)
* [Review Environments](/flxbl/codev/inspect/review-environments.md)
* [Integrations: Source Control](/flxbl/codev/integrations/source-control.md)


---

# 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.flxbl.io/flxbl/codev/issueops/issueops.md?ask=<question>&goal=<endgoal>
```

`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.