# Handling member account deletion

As you run "Cozy Closet," your online clothing store, there are days when a shopper who signed up gets in touch asking you to delete their account. Imagine Emma, who had taken on the Review Moderator role, sent you a request like that. At that point operators need to know where to go and what to click, and they also have to decide what to do with the reviews and photos that member left behind.

This page covers removing a signed-up member (*ServiceUser*, a shopper who signed up for your service directly) from the roster. It walks through how to provide a place for shoppers to request deletion inside your app, the steps you take in the content studio, and how to decide whether to delete what the member created along with them.

## Member removal is done in the content studio {#where-withdrawal-is-processed}

You handle member removal in the content studio. There is no path open for a member to remove their own account by pressing a button in your app.

A member, and what that member created, never disappears without operators knowing. So you should provide a place in your app for receiving deletion requests, and carry out member removal in the content studio once an operator has reviewed the request.

## Taking deletion requests in the app {#receiving-requests-in-the-app}

Only operators can carry out a removal. So the place where a shopper conveys their intention to leave has to be provided in the app itself. The recommended approach is to receive each deletion request as one *Content*. When a member leaves a request in the app, operators read that list in the content studio and remove the members they have confirmed from the roster.

Depending on where you publish your app, you may be required to provide a place inside the app from which deletion can be started. This request flow serves as that place.

### Creating the Content Type that holds the request {#modeling-the-request-content-type}

First, create one *Content Type* to hold deletion requests. For "Cozy Closet," name it `Account Deletion Request`, and two things to hold are enough.

- `Reason`: what the member writes in the app. For example, it comes in as "I don't buy clothes very often anymore."
- `Status`: a value operators change themselves. It starts as `Received` and changes to `Done` once handling is finished.

You do not need to record separately who sent the request. When a member creates one *Content* in the app, that member is recorded as its author. How to create a *Content Type* is covered in [Content Modeling](/getting-started/core-concepts/content/content-modeling.md).

### Members get only Create and Read {#permissions-for-the-request}

When you add rules for this *Content Type* to the permission bundle granted to members (*ServiceUserRole*), open only these two.

- **Create**: Lets a member leave one deletion request. Leave the **Author** as **Any Users**.
- **Read**: Lets a member check in the app whether their request was received. On this rule, set the **Author** to **The role holder**. That way they cannot look into other members' requests.

Do not include **Delete**. If members removed their requests at will, operators would have no way to know what still needs handling. The screen where you add a single rule, and how to handle the **Author** field, are covered in [Member Roles and Permissions](/getting-started/core-concepts/service-users/service-user-role.md#the-key-is-only-what-you-created-yourself).

## Removing a member in the content studio {#processing-in-the-studio}

Once you have checked Emma's request in the `Account Deletion Request` list, find that member in the member roster and remove them. Where you open the roster and what information the list shows are covered in [Managing service members](/operations/service/managing-members.md#where-members-are-listed).

1. In the **Users** list, click the expand icon at the far-right end of the row of the member you are removing (Emma).
2. Click **Remove User** at the bottom left of the expanded panel. It sits opposite **Save**.
3. When the window opens, type that member's email address (`emma@example.com`) exactly.
4. Decide whether to delete what that member created as well, and turn **Also delete every Content and Media this user created** on or off. How to decide is covered in [What goes with the member, and how long it takes](#what-goes-with-the-member).
5. Click **Remove User**.

![The expanded detail for member Emma's row in the Users list. Below the Role in the permissions section and the login-allowed toggle in the account section, a red-outlined Remove User button sits at the far left and the Cancel and Save buttons sit at the far right](/_img/en-US/getting-started/core-concepts/service-users/images/account-deletion-01-remove-entry.webp)

Clicking **Remove User** opens a confirmation window.

![The ServiceUser removal window. A card at the top holds the member being removed, Emma (emma@example.com), and below it are the notice that this user immediately loses access to this Space and that signing up again with the same account registers them as a separate ServiceUser, an empty email confirmation field, the switched-off "Also delete every Content and Media this user created" checkbox, and the Remove User button, which cannot be clicked yet](/_img/en-US/getting-started/core-concepts/service-users/images/account-deletion-02-remove-dialog.webp)

The email address has to match that member's before the **Remove User** button can be clicked. This confirmation is not a step for asking the member's consent. It is a device that makes operators read one more time whether the row they picked really is that member. If you clicked one row below the one you meant, this step stops you.

Once the removal is finished, the following four things apply right away.

- That member immediately cannot get into this *Space* and cannot log in again.
- They disappear from the roster right away.
- If they sign up again later with the same social account, it is not connected to the old record, and they are registered as a separate member.
- This removal cannot be undone.

The last item is what makes it different from blocking a login. [Blocking a problem member's login](/operations/service/managing-members.md#blocking-a-member) lets you hold a member out for a while and then let them back in, but a member you have removed cannot be brought back. If the situation calls for leaving room to come back, use login blocking instead.

If you are keeping the request records, change the `Status` of that `Account Deletion Request` to `Done` once you have finished.

## What goes with the member, and how long it takes {#what-goes-with-the-member}

The removal window has an **Also delete every Content and Media this user created** checkbox, and its default is off. Removing a member and deleting what that member created are separate things, so operators decide case by case whether to delete both.

If you carry out the removal without turning the checkbox on, the reviews Emma wrote and the photos she uploaded stay in the *Space* as they are. Only the member who was their author is gone. Choose this when the review content keeps being useful to other shoppers.

If you carry out the removal with the checkbox on, the *Content* and *Media* that member created are deleted afterward. Choose this when leaving that one person's material behind is a problem, such as photos the member uploaded.

Deleting the *Content* and *Media* proceeds after the removal itself is finished. What the member created does not disappear all at once, but is deleted one item after another. It can take a long time when there are many, so if some are still left in the list, check again after some time has passed.

> A deletion request is also a *Content* the member created. So if you carry out the removal with **Also delete every Content and Media this user created** turned on, that request record disappears too. If you need a history of who requested deletion and when, record it separately somewhere the member is not the author. That means keeping one more *Content Type* as a handling log that operators create themselves, and writing a line in it whenever you review a request.

## What to do next {#what-to-do-next}

- [Managing service members](/operations/service/managing-members.md): Covers how to read the member roster, approve new sign-ups, block a login, and give different permissions to different members.
- [Member Roles and Permissions](/getting-started/core-concepts/service-users/service-user-role.md): Covers how to create the *ServiceUserRole* that grants members permission to leave and read deletion requests.
- [Service Member Login](/getting-started/core-concepts/service-users/service-login.md): Covers how to turn on member login, connect social login, and decide the **Default Role** that newly signed-up members receive.
- [API Reference](/api/reference/acma.md): Covers technical specifications such as the request format used when a member leaves a deletion request in the app.