# Member Roles and Permissions

Imagine you run a clothing shop called "Cozy Closet." You want signed-up shoppers to write reviews directly on your products. At the same time, you want shoppers to be able to edit or delete their own reviews, but not touch reviews written by others. A bundle of permissions that decides "what each signed-up member can see and what they can write" is a *ServiceUserRole* (a permission bundle granted to signed-up members).

A *ServiceUserRole* applies to signed-up members, that is, to a *ServiceUser* (a shopper who signed up directly for your service). Instead of assigning permissions to each member one by one, you create a permission bundle such as "can write reviews" once and attach it to members.

This page first looks at what a *ServiceUserRole* is and how it differs from staff permissions, then walks through creating a role in "Cozy Closet" that lets members write reviews and edit only their own reviews.

## Member roles are different from staff roles {#member-roles-are-different-from-staff-roles}

WEEGLOO has two kinds of permission bundles. They are easy to confuse, so let's draw the line first.

- *SpaceRole* is the permission granted to **staff and the team**. It is the permission of the people who register products and manage the site, and it is covered in [Roles and Permissions](/getting-started/core-concepts/access-and-permissions/role-and-permissions.md).
- *ServiceUserRole* is the permission granted to **signed-up members**. It decides what shoppers who signed up directly on the clothing shop site with a social account can see and write.

In short, *SpaceRole* is the permission of "the people who run the shop," and *ServiceUserRole* is the permission of "the shoppers who visit the shop." The two are entirely different roles, so a role created on one side does not apply to the other. This page covers only the *ServiceUserRole* granted to members.

## The way you build rules is the same as for staff roles {#the-way-you-build-rules-is-the-same-as-for-staff-roles}

The screen for creating a member role works exactly the same way as the screen for creating a staff role. The role creation screen is split into tabs (**Role detail** ,  **Content Type** ,  **Content** ,  **Media** ,  **Script**), and in each resource tab you add rules one line at a time to an **Allowed** list and a **Denied** list. A single rule is a combination of "which action ,  on which *Content Type* ,  created by whom ,  with which *Tag* attached" it applies to. And **anything you do not put in the allow list is automatically denied.**

How the rule builder works (allow and deny, the kinds of actions, narrowing the scope) is covered in detail in [Roles and Permissions](/getting-started/core-concepts/access-and-permissions/role-and-permissions.md). This page focuses on the most important part of member permissions: how to let members handle only what they created themselves.

## The key is "only what you created yourself" {#the-key-is-only-what-you-created-yourself}

When you let members write reviews, the most common need is to let a member edit and delete **only their own reviews**. They must not be able to edit other people's reviews.

A single rule has a field for choosing the **Author**. There are three values you can choose here.

| Author value | Applies to |
|---|---|
| **Any Users** | Everything, no matter who created it |
| **The role holder** | Only what the member the rule applies to created themselves |
| Specific user | Only what one designated person created |

![The Author field of an Edit rule, opened. Along with Any Users and The role holder, the name of a user you can designate appears in the list](/_img/en-US/getting-started/core-concepts/service-users/images/service-user-role-03-author-options.webp)

If you choose **The role holder** here, the rule applies to "what I created" for each member individually. Even when many members hold the same role, each one only targets what they themselves created.

To put it in the clothing shop example, if you allow Edit and Delete on reviews (*Content*) but set the **Author** to **The role holder**, members can edit and delete only their own reviews. Reviews written by others appear in the list but cannot be touched.

> What a member can touch is decided by this role. If you do not set the **Author** to **The role holder**, that action applies to what other people wrote as well, so do not leave **The role holder** out of your edit and delete rules.

## Script execution permission {#script-permission}

A member role can also carry permission over a *Script*. A *Script* is a backend gateway your website calls, built without any server code (see [Script](/getting-started/core-concepts/deployment-and-integration/script.md)). For signed-up members, though, the only permission you open is **Execute**.

- **Execute**: Lets a member call (run) that *Script*. A member needs this permission to call a *Script* from the website.

Creating, editing, and deleting *Script*s is the job of the staff who use the content studio, so a member role usually carries only **Execute**. The way you set permissions with allow and deny rules is itself the same as for staff roles, and the screen for adding a Script permission as a rule is covered in [Roles and Permissions](/getting-started/core-concepts/access-and-permissions/role-and-permissions.md#script-permission).

<!-- Script 탭 확인 완료: ServiceUserRole 편집기 탭 바는 Role 상세·Content Type·Content·Media·Script 5개(캡쳐 service-user-role-01-create-detail.png에 반영). Script 권한 규칙을 넣는 상세 화면은 SpaceRole과 동일 UI라 [역할과 권한#script-permission]에서 다룬다(중복 캡쳐 지양). 캡쳐는 ServiceLogin 활성 데모 Space(v4j6LHKk)에서 촬영. -->

## Creating the "Regular Member" role {#creating-the-regular-member-role}

Now let's create the "Regular Member" role to grant to newly signed-up members in "Cozy Closet." This role will be able to read all reviews (*Content*) (Read), write new ones (Create), and edit the reviews they wrote (Edit, author = themselves).

Member roles are created under **Roles** within *ServiceLogin* (the login setting that lets shoppers sign up and use the service directly).

1. In the left menu, expand **Services** and click **ServiceLogin**.
2. Click **Roles**.
3. Click the **Create** button at the top right to open the role creation screen.

<!-- 캡쳐 보류: Roles 목록 화면은 ServiceLogin이 실제로 활성화돼야 정상적으로 보인다(비활성 상태에선 안내만 나옴). 활성화 환경이 준비되면 목록 + 생성 버튼을 촬영. -->

Once the role creation screen ("Create ServiceUserRole") opens, first set the name.

4. In the name field of the **Role detail** tab, enter `Regular Member`. You can leave the description field empty.

![The Role detail tab of the Create ServiceUserRole screen, with "Regular Member" entered as the name](/_img/en-US/getting-started/core-concepts/service-users/images/service-user-role-01-create-detail.webp)

Next, set the actions members can take on reviews (*Content*). Reviews must be created as a separate *Content Type* (the review form template) so that rules can pick that kind and apply to it.

5. Go to the **Content** tab. Along with the guidance "Set the Content access scope by combining action, Content Type, author, and Tag," you will see the **Allowed** and **Denied** lists.
6. Use the **+** button under **Allowed** to add one rule. Set the action to **Read**, choose "Reviews" as the *Content Type*, and leave the **Author** as **Any Users**. This lets members read all reviews.
7. Add one more rule the same way. Set the action to **Create**, choose "Reviews" as the *Content Type*, and leave the **Author** as **Any Users**. This lets members write new reviews.
8. Add one more rule. Set the action to **Edit**, choose "Reviews" as the *Content Type*, then change the **Author** to **The role holder**. This lets members edit only the reviews they wrote.

![The Content tab allow list, with three rules limited to "Reviews": Read (all users), Create (all users), Edit (author themselves)](/_img/en-US/getting-started/core-concepts/service-users/images/service-user-role-02-content-allow.webp)

9. Click the **Save** button at the top right.

When `Regular Member` appears in the list, the role has been created.

> To also let members delete reviews, add one more rule the same way, with the action set to **Delete**, the *Content Type* set to "Reviews," and the **Author** set to **The role holder**.

## Applying the role you created to members {#applying-the-role-you-created-to-members}

Creating a role does not automatically apply it to members. A role you create takes effect only after you connect it to members.

The most common way is to set the `Regular Member` role you just created as the **default Role** in [Service Member Login](/getting-started/core-concepts/service-users/service-login.md). Then this role is automatically attached to every newly signed-up member.

There are also times when you want to give only a specific member different permissions. For example, if you want to give a VIP member broader permissions, you can assign a different role to that one member separately (per-member override). The screen for assigning a role to one member is covered in [Managing service members](/operations/service/managing-members.md#overriding-a-members-role).

The same approach works when you want a member who cleans up what other members wrote. Create one more role whose delete rule has the **Author** set to **Any Users**, and assign that role only to the member you put in charge of the cleanup. Newly signed-up members still receive `Regular Member`, the **default Role**, so the broader permission goes only to the member you assigned it to.

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

- [Service Member Login](/getting-started/core-concepts/service-users/service-login.md): Connect the role you created as the default Role and turn on social login.
- [Roles and Permissions](/getting-started/core-concepts/access-and-permissions/role-and-permissions.md): Covers how to set permissions for staff (the team) with the same rule builder.
- [API Reference](/api/reference/acma.md): Covers technical specifications such as request formats for working directly with the content members read and write from a program.