# Follow one customer request from the form to the changelog > How Intake, Customers, a cycle, and a release work together on one customer request, from the form a customer fills in to the changelog of the release that ships it. Lesson 12 of 12 in Plane Business · 3:55 · [Watch the lesson](https://academy.plane.so/videos/request-to-release) ## Chapters - [0:00](https://academy.plane.so/videos/request-to-release?t=0) Follow one request through Plane - [0:33](https://academy.plane.so/videos/request-to-release?t=33) Accept the request and attach the customer - [1:49](https://academy.plane.so/videos/request-to-release?t=109) Plan the work and follow it - [2:38](https://academy.plane.so/videos/request-to-release?t=158) Ship it and close the loop - [3:36](https://academy.plane.so/videos/request-to-release?t=216) See the request's whole trail ## Follow one request through Plane This lesson follows one customer request through Plane, from the form a customer fills in to the changelog of the release that ships it. It puts several features to work together on a single request: Intake, Customers, a cycle, and a release, with where to look at each step. ## Accept the request and attach the customer On Business and higher, a project admin can give the project's Intake a public form and an email address, so customers need no Plane account to send a request. A customer fills in the form with a name, an email, a title, and a description. After the confirmation page, Plane sends them nothing. The request arrives in Intake as **Pending**, already a work item with its own ID. Intake responsibility assigns it to whoever the project picked to review requests. 1. A project admin chooses **Accept**. In the form that opens, set its state, priority, assignees, and labels before it joins the project. 2. Choose **Add to project**. The request moves to Intake's **Closed** tab as **Accepted**, and the work item keeps the same ID. 3. From the work item, a workspace admin chooses **Customer request**, picks the customer, names the request, and chooses **Create request**. The customer's record now holds the request, linked to the work item, and the work item's details name the customer and the request. ## Plan the work and follow it 1. Set the work item's **Cycle** to the current cycle, so it's planned with the rest of the team's work. The list leaves out cycles that have ended. 2. The engineer moves it through **To do** and **In progress** to **In review**, then adds the QA engineer as an assignee to test it. Plane subscribed whoever added the request to the work item, so each of those changes reaches their **Inbox**. To check progress without asking the team, open the customer's record. The request there lists the work item with its current state, priority, and assignees. Once it passes testing, the QA engineer moves it to **Done**, and the cycle's progress counts it as completed. ## Ship it and close the loop 1. To ship it, pick a release in the work item's **Releases** property. A workspace release takes work items from any project. 2. On the target date, once everything in the release's **Scope** is done or cancelled, a workspace admin chooses **Release now**. 3. With nothing unresolved, the dialog only says how many work items will be released and shows the date. Choose **Release**. Plane sets the status to **Released** and saves that date. It doesn't deploy anything, so your team still ships the code its usual way. Then write the **Changelog** in the customer's terms. People with access to the release can read it, but Plane doesn't send it to customers. Back on the customer's record, the request's work item reads **Done**. Open it, and its **Releases** property shows the release that shipped it. ## See the request's whole trail Intake took the request in, the customer's record kept it linked, a cycle planned the work, and a release shipped it. ## Try it Open a pending request in a project's Intake, choose Accept, set its state and assignees, and choose Add to project. Then, on the work item, choose Customer request and pick the customer. ## Plans - Business: Intake email and forms, Intake responsibility, customers, and releases ## Docs - [Intake](https://docs.plane.so/intake/overview) - [Customers](https://docs.plane.so/customers) - [Releases](https://docs.plane.so/releases) ## Transcript ### Follow one request through Plane This lesson follows one customer request through Plane, from the form a customer fills in to the changelog of the release that ships it. Most earlier lessons in this playlist set up one feature each. This one puts several of them to work together on a single request. You'll follow the request through Intake, Customers, a cycle, and a release, and see where to look at each step. Let's take a closer look. ### Accept the request and attach the customer On Business and higher, a project admin can give the project's Intake a public form and an email address, so customers need no Plane account to send a request. A customer fills in the form with a name, an email, a title, and a description. After the confirmation page, Plane sends them nothing. The request arrives in Intake as Pending, already a work item with its own ID. Intake responsibility assigns it to whoever the project picked to review requests. A project admin chooses Accept. In the form that opens, they set its state, priority, assignees, and labels before it joins the project. Choose Add to project. The request moves to Intake's Closed tab as Accepted, and the work item keeps the same ID. From the work item, a workspace admin chooses Customer request, picks the customer, names the request, and chooses Create request. The customer's record now holds the request, linked to the work item, and the work item's details name the customer and the request. ### Plan the work and follow it Set the work item's Cycle to the current cycle, so it's planned with the rest of the team's work. The list leaves out cycles that have ended. The engineer moves it through To do and In progress to In review, then adds the QA engineer as an assignee to test it. Plane subscribed whoever added the request to the work item, so each of those changes reached their Inbox. To check progress without asking the team, open the customer's record. The request there lists the work item with its current state, priority, and assignees. Once it passes testing, the QA engineer moves it to Done, and the cycle's progress counts it as completed. ### Ship it and close the loop To ship it, pick a release in the work item's Releases property. A workspace release takes work items from any project. On the target date, everything in the release's Scope is done or cancelled, and a workspace admin chooses Release now. With nothing unresolved, the dialog only says how many work items will be released and shows the date. Choose Release. Plane sets the status to Released and saves that date. It doesn't deploy anything, so your team still ships the code its usual way. Then write the Changelog in the customer's terms. People with access to the release can read it, but Plane doesn't send it to customers. Back on the customer's record, the request's work item reads Done. Open it, and its Releases property shows the release that shipped it. ### See the request's whole trail Intake took the request in, the customer's record kept it linked, a cycle planned the work, and a release shipped it.