> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fga.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing Relationships Between Objects

> Granting a user access to a particular object through a relationship with another object

In this guide you will learn how to grant a user access to a particular object through a relationship with another object.

**When to use**

Giving user access through a relationship with another object is helpful because it allows scaling as the number of object grows. For example:

* organization that owns many repos
* team that administers many documents

## Before you start

In order to understand this guide correctly you must be familiar with some [Auth0 FGA Concepts](https://docs.fga.dev/fga-concepts.md) and know how to develop the things that we will list below.

<details>
  <summary>
    Assume that you have the following [authorization model](https://docs.fga.dev/fga-concepts.md#what-is-an-authorization-model)\\

    * a `repo` type that can have a `admin` relation
  </summary>

  ***

  In addition, you will need to know the following:

  ### Direct access

  You need to know how to create an authorization model and create a relationship tuple to grant a user access to an object. [Learn more →](https://docs.fga.dev/modeling/basics/modeling-basics.md)

  ### Auth0 FGA concepts

  * A [Type](https://docs.fga.dev/fga-concepts.md#what-is-a-type): a class of objects that have similar characteristics
  * A [User](https://docs.fga.dev/fga-concepts.md#what-is-a-user): an entity in the system that can be related to an object
  * A [Relation](https://docs.fga.dev/fga-concepts.md#what-is-a-relation): is a string defined in the type definition of an authorization model that defines the possibility of a relationship between an object of the same type as the type definition and a user in the system
  * An [Object](https://docs.fga.dev/fga-concepts.md#what-is-an-object): represents an entity in the system. Users' relationships to it can be define through relationship tuples and the authorization model
  * A [Relationship Tuple](https://docs.fga.dev/fga-concepts.md#what-is-a-relationship-tuple): a grouping consisting of a user, a relation and an object stored in Auth0 FGA
</details>

## Step by step

For the current model, a [user](https://docs.fga.dev/fga-concepts.md#what-is-a-user) can be related as an `admin` to an [object](https://docs.fga.dev/fga-concepts.md#what-is-an-object) of [type](https://docs.fga.dev/fga-concepts.md#what-is-a-type) `repo`. If we wanted to have Anne be related to two repos, `repo:1` and `repo:2`, we would have to add two [relationship tuples](https://docs.fga.dev/fga-concepts.md#what-is-a-relationship-tuple), like so:

In general, every time we wanted to add a new `admin` relationship to a `repo` we'd have to add a new tuple. This doesn't scale as the list of `repo`s and users grows.

### 01. Modify authorization model

Another way of modeling this is to have an authorization model as follows:

In this model, we have:

* added a new type `org` with one relation `repo_admin`.
* added a new relation `owner` for type `repo`.
* re-defined the relation `admin` for `repo`. A user can be defined as an `admin` directly, as we have seen above, or through the `repo_admin from owner` clause. How this works, for example, is that if `user` is related as `repo_admin` to `org:xyz`, and `org:xyz` is related as `owner` to `repo:1`, then `user` is an `admin` of `repo:1`.

### 02. Adding relationship tuples where user is another object

With this model, we can add tuples representing that an `org` is the `owner` of a `repo`. By adding following relationship tuples, we are indicating that the xyz organization is the owner of repositories with IDs `1` and `2`:

### 03. Adding relationship tuples to the other object

Now, imagine we have a new user Becky. If we wanted to have Becky be the `admin` of all `repo`s without having to add one tuple per `repo`, all we need to do is add one tuple that says that Becky is related as `repo_admin` to `org:xyz`.

### 04. Validating user access

We can now verify that Becky an `admin` of all the `repo`s owned by `org:xyz`:

### 05. Revoking access

Suppose now that we want to prevent users from being an `admin` of `repo:1` via `org:xyz`. We can delete one tuple:

With this change, we may now verify that Becky is no longer an `admin` of `repo:1`.

## Related Sections

Check the following sections for more on how to model relationships between objects.

[Modeling Parent-Child Objects
Learn about how to cascade relationships from parent object to child object.](https://docs.fga.dev/modeling/basics/parent-child.md)

[Modeling Object to Object Relationships
Learn about modeling patterns on objects that are not specifically tied to a user.](https://docs.fga.dev/modeling/concepts/object-to-object-relationships.md)

[Modeling GitHub
An example of object to object relationships.](https://docs.fga.dev/modeling/advanced/use-cases/github.md)