> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bytebase.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Issue
> Record a request's review, discussion, and approval in Bytebase.
Custom approval flows require **Enterprise**. Plans and their linked Issues also exist without this feature; in that case, review requires no human approval.
An **Issue** is a request for review or approval in Bytebase. It records the request, its approval flow, and reviewers' discussion and decisions. For a database change, the Issue is linked to the Plan that defines the work. Other Issue types handle requests for roles or temporary database access.
For example, a developer proposes adding a column to an application's database. The Plan holds the SQL and targets; its Issue records the reviewers, feedback, and approval.
## Issue versus Plan
A **Plan** manages the database change from preparation through deployment. Its **Issue** manages review and approval. Submitting a Plan for review submits its linked Issue; it does not convert the Plan into an Issue or replace it.
For changes to existing databases, **Review** on the Plan page displays the Issue. An Issue link opens that same page, so authors and reviewers can see the SQL, discussion, and deployment together.
## Create and submit a review request
For a schema or data change in the UI, **Create** saves the Plan and its linked draft Issue. The author prepares the SQL and checks, then clicks **Ready for Review** to submit the Issue. Bytebase determines the approval flow from the configured rules.
In the [GitOps workflow](/gitops/migration-based-workflow/tutorial), pull-request review and CI checks take place before deployment. Release-based Plans have no Bytebase Issue review phase.
Other requests have their own entry points: **Create Database** opens its Issue workflow directly, while role and temporary-access requests follow [database access roles](/security/database-permission/request) and [Access Grants](/security/database-permission/grant).
## Review a database change
Open **Review** on the Plan. Read the proposed SQL and target databases, then inspect the approval flow to see whose decision is required. Add comments to discuss the change. An eligible reviewer uses **Review** to approve or reject it.
Approval rules select the reviewer roles and any required sequence. For example, a flow may require a Project Owner's approval followed by a Workspace Admin's. Permission to read or comment does not itself grant permission to approve.
If feedback requires changes, the author updates the Plan's SQL and checks the new automated results and approval state before proceeding.
## Understand the approval outcome
* **Draft:** the request has been saved but not submitted for review.
* **Under review:** approval is pending; the flow identifies the current reviewer.
* **Approved:** the required review decisions are complete. Execution has its own status under **Deploy**.
* **No approval required:** the configured flow needs no reviewer decision. The UI can show **Skipped** or **Bypassed**; read the approval flow and activity to understand why.
In this example, **Approval Flow** says **No approval required**, and Activity records that review was skipped and the Rollout created. The **Bypassed** badge describes that outcome; it does not show a reviewer overriding a requirement.
For submitted UI changes to existing databases, Bytebase automatically creates the Rollout after approval is satisfied and checks finish without errors. Approval alone does not mean the SQL has executed.
See [Custom Approval](/change-database/approval) to configure rules, or the [UI tutorial](/tutorials/first-schema-change) to follow a complete change.