Skip to content Skip to main navigation Skip to footer

Overview of Permissions in GIS Cloud

When sharing your map with other users, be it users in the field or in the office, you can set permissions for each user or user group. By defining options for every user individually, you can decide who can view, edit, share, export, collect, or update data.

Permissions in GIS Cloud can be set from the Map Editor and Mobile Data Collection Portal. Map permissions can be set from both the Map Editor and Mobile Data Collection Portal, while Layer permissions can be set only from the Map Editor.

Below you can find the breakdown of all map and layer permissions in GIS Cloud.

Table of Contents

Map Permissions

Check out how to share your map from the Mobile Data Collection Portal and Map Editor.

  • Can view – will provide only viewing privileges to the person you have shared your map with.
  • Can share – will provide sharing privileges to the person you have shared your map with.
  • Can edit – will provide complete editing privileges to the person you have shared your map with.
  • Can export – will allow the person to export the map you have shared with them.
  • Can collect – will allow the person in the field to send new data, without the possibility of making changes to existing data or the one that they have already sent through the Mobile Data Collection app.
  • Can update – will allow the person in the field to make attribute and geometry changes, without the possibility of sending new data through the Mobile Data Collection application.

Note: Map permissions apply to all layers on the map as well. In order to give other users permissions only for specific layers, you have to remove the map permissions and apply only the layer permissions.

Layer Permissions

Click here to learn how to set up additional sharing options for each layer individually. 

  • Can view – will allow the person you have shared your map with only viewing privileges of the specified layer, without the possibility to edit or export it. Note that you cannot remove this permission to hide a particular layer.
  • Can share – will provide sharing privileges to the person you have shared your layer with. E.g., If you gave view privileges to the map, but want to enable another user to share a layer with a third user. A person with share privileges can share a layer with a user and assign them the same permissions they got from the layer owner.
  • Can edit – will provide the person you have shared your map with complete editing privileges of the specified layer. E.g., If you give a user view privileges to the map, but want them to be able to edit a specific layer.
  • Can export – will allow the person to export specific layers from the map you have shared with him. E.g., If you give a user view privileges to the map, but want them to be able to export a specific layer.
  • Can collect – will allow the person in the field to send new data to a specific layer but without the possibility to make changes to existing data or the one that they already sent through the Mobile Data Collection application.

AI and Permissions

AI in GIS Cloud — both the in-app Ask AI chat and external assistants connected via GIS Cloud MCP — acts as the signed-in user. It does not bypass your existing map or layer permissions: it can only do what that user could already do themselves through the UI or API.

Why this exists. Because AI lets people describe changes in plain language instead of using the UI or API directly, GIS Cloud added a separate AI-access setting so that sharing your data doesn’t automatically extend to AI use — you decide that separately.

The AI access setting. In Account Settings, you control whether the people you’ve shared your maps, layers, or datasources with can use AI (in-app or via MCP) to work with that data. There are two toggles, both off by default:

  • Read and contribute — AI can read the shared data and insert new records (non-destructive).
  • Update and delete — AI can also modify and delete the shared data.

This only affects other people’s AI access to data you’ve shared with them. It has no effect on your own AI access to your own data — as the owner, you can already do anything through AI that you could do through the UI or API.

How it combines with regular permissions — it only narrows, never grants:

  • If you haven’t enabled at least “Read and contribute,” a person cannot use AI to even read that data — regardless of what permission they hold on it. Someone with “Can edit” on a layer still can’t ask the chat about it if you haven’t turned this on.
  • Enabling AI access doesn’t hand out any capability the person doesn’t already have. If someone only has “Can view” and “Can export” on a layer, turning on “Update and delete” for AI does nothing for them — they still need “Can edit” on that layer before AI (or the API, or the UI) can change it on their behalf.

In short: the regular map/layer permissions still decide what someone is allowed to do; the AI toggles decide whether AI is allowed to act on it at all. Both have to allow it.

For the full list of what Ask AI and GIS Cloud MCP can do, see GIS Cloud AI — The In-App Assistant and AI Connectors (MCP).

Setting permissions using the GIS Cloud API

It is possible to set permissions for both maps and layers using the GIS Cloud API. The GIS Cloud API documentation is available here.

Map Permissions

Map permissions are granted using the resource ID of the map. To get the map’s resource ID:

Endpoint:

GET https://api.giscloud.com/1/maps/{MAP_ID}.json

Example request:

curl -H "API-Key: {USER_API_KEY}" "https://api.giscloud.com/1/maps/{MAP_ID}.json"

The response contains a top-level resource_id (values below are from a real response and will differ for your account/map):

{
    "id": "3235514",
    "name": "mapB",
    ...
    "resource_id": "43827498",
    "resource": {
        "id": "43827498",
        ...
    },
    ...
}

Use resource_id in the following request to grant permission:

Endpoint:

POST https://api.giscloud.com/1/resources/{RESOURCE_ID}/permissions.json

Example request:

curl -H "API-Key: {USER_API_KEY}" -X POST -d '{"username": "{USERNAME}", "permission": "READ"}' https://api.giscloud.com/1/resources/{RESOURCE_ID}/permissions.json

You can find the full list of permissions here.

Layer permissions

In GIS Cloud, every layer is backed by a datasource. To grant layer permissions, you need the resource ID of that datasource — not the layer’s own resource ID. Request the layer with expand=datasource:

Endpoint:

GET https://api.giscloud.com/1/layers/{LAYER_ID}.json?expand=datasource

Example request:

curl -H "API-Key: {USER_API_KEY}" "https://api.giscloud.com/1/layers/{LAYER_ID}.json?expand=datasource"

⚠️ The response contains two different resource_id fields — do not confuse them (values below are from a real response and will differ for your account/layer):

{
    "id": "7819633",
    ...
    "resource_id": "43827500",
    ...
    "datasource": {
        "resource_id": 43827495,
        "type": 15,
        "owner_id": 217383,
        "permissions": ["OWNER"]
    },
    ...
}
Fieldwhat it isuse for permissions?
top-level resource_idThe layer’s own resource ID❌ No
datasource.resource_id (nested)The resource ID of the layer’s underlying datasource✅ Yes

These two values are typically close in number, which makes them easy to mix up — always read datasource.resource_id from the nested object, not the top-level field.

Use datasource.resource_id in the following request to grant permission:

Endpoint:

POST https://api.giscloud.com/1/resources/{DATASOURCE_RESOURCE_ID}/permissions.json

Example request:

curl -H "API-Key: {USER_API_KEY}" -X POST -d '{"username": "{USERNAME}", "permission": "EDIT"}' https://api.giscloud.com/1/resources/{DATASOURCE_RESOURCE_ID}/permissions.json

End-to-end API example

Say you want to share a map with a user so they can view the map and all its layers, but edit only one specific layer.

Map permissions apply to all layers on the map, so a single READ grant on the map covers viewing everything. You then only need one additional EDIT grant on the specific layer’s datasource resource ID — you do not need to separately grant READ on the layer itself.

1. Get the map’s resource ID (map ID 3235514):

curl -H "API-Key: {USER_API_KEY}" "https://api.giscloud.com/1/maps/3235514.json"

Response (trimmed): 

{
    "id": "3235514",
    "name": "Pipe inspection - field crew A",
    "resource_id": "43827498",
    ...
}

2. Grant view access to the whole map using that resource ID:

curl -H "API-Key: {USER_API_KEY}" -X POST -d '{"username": "gc_user", "permission": "READ"}' https://api.giscloud.com/1/resources/43827498/permissions.json

3. Get the layer’s datasource resource ID (layer ID 7819633):

curl -H "API-Key: {USER_API_KEY}" "https://api.giscloud.com/1/layers/7819633.json?expand=datasource"

Response (trimmed): 

{
    "id": "7819633",
    "resource_id": "43827500",
    "datasource": {
        "resource_id": 43827495,
        ...
    },
    ...
}

Remember: use datasource.resource_id (43827495), not the top-level resource_id (43827500).

4. Grant edit access to that one layer using the datasource resource ID:

curl -H "API-Key: {USER_API_KEY}" -X POST -d '{"username": "gc_user", "permission": "EDIT"}' https://api.giscloud.com/1/resources/43827495/permissions.json

Result: gc_user can view the map and every layer on it, and can additionally edit the one layer backed by datasource 43827495.

Was This Article Helpful?