Sharing & access keys
A project belongs to one person, and everyone else who can open it is on its member list. Inside your organization you add them by name; outside it you hand over a one-time key. Both are set up in one dialog, on terms you choose once.
Two ways in
A project belongs to one person. Everyone else who can open it is on its member list, and there are exactly two ways onto that list. Inside your organization you pick the person by name and press Give access. Outside it there is nobody to look up, so you copy a one-time access key and hand it over.
Both routes start in the same dialog, PROJECT ACCESS, and both end with the recipient using Open From Parametra to download the project onto their own machine. See Opening from Parametra for the receiving end.
The project has to be on Parametra before it can be shared. A project with no server id has no server copy to grant access to, and the dialog says so: “This project is not on Parametra yet — upload it from the footer's warning button first.” Do that, then come back — see Saving, syncing, versioning.
Opening Project Access
Access is handed out from the account popup, not from inside the project. Opening a project starts a work session, and granting a colleague access is not work on the city.
- Click the user icon in the iCity Editor header to open the ACCOUNT popup, then choose Projects in the left rail.
- Find the project's row. Each row shows its name and a meta line to the right of it: its latest version, its owner, how many work sessions it has had, and the credits spent on it. Parts of that line are omitted when they have nothing to report.sharing-access-keys-account-projects.png
The ACCOUNT popup open on the Projects section, signed in as an organization admin, showing at least two project rows. One row must show its right-hand meta text (version, owner, sessions, credits) and the Access button at the end of the row.
/docs-shots/blender/The Projects section of the ACCOUNT popup, with the Access action on a project row. - Click Access on the row. The PROJECT ACCESS dialog opens over the viewport, headed “Everyone here can open this project and sync it. Access is per project.”sharing-access-keys-access-dialog.png
The PROJECT ACCESS dialog open, showing the intro line, the HAS ACCESS heading with the owner row tagged 'owner', the ADD FROM YOUR ORGANIZATION heading with the Gives terms row beneath it and at least one colleague row with a Give access button, and the Copy access key button at the bottom left.
/docs-shots/blender/The PROJECT ACCESS dialog: who has access now, and who can be added.
This is a drawn dialog, so it needs a 3D viewport in the iCity 2 workspace to appear in. Pressing Access from anywhere else writes a line in the log saying the dialog needs a 3D viewport in the iCity workspace, and nothing opens.
Who can grant what
The server decides who may grant, and the dialog never guesses ahead of it: it offers the action and shows the server's reason when it is refused.
The Access button on a project row is drawn for organization admins and owners. If you are not an admin, or your account is not in an organization at all, your projects are still listed but their rows carry no Access button, so the dialog has no way in from the interface.
In Open From Parametra, a project you can see but not open has a padlock button on its row. Pressing it does not send anything yet: it marks the row “sent” for this session, and the log tells you to ask an administrator to grant access from Account ▸ Projects.
Setting the terms once
Under ADD FROM YOUR ORGANIZATION there is a row labelled Gives with two buttons. They are cyclers: each press steps to the next option. You set them once, and every grant you then hand out carries those terms.
A close crop of the Gives row inside the PROJECT ACCESS dialog, under the ADD FROM YOUR ORGANIZATION heading, with the left button reading a pinned version such as '1.0' and the right button reading '30 days'.
The terms are read at the moment you press Give access, so changing them afterwards does not change grants already made. To change someone's terms, Remove them, set the new terms, and give access again.
Giving access to a colleague
The dialog lists everyone who can open the project under HAS ACCESS, the owner first and tagged owner. Everyone else in your organization who does not have access yet is listed underneath.
- Set the two buttons in the Gives row.
- Press Give access on the person's row. They move up into HAS ACCESS.
- Their row now spells the terms out after their name —
v1.0 onlyfor a pinned grant,until 2026-09-25for a temporary one, and nothing at all for full permanent access.
The HAS ACCESS list in the PROJECT ACCESS dialog showing the owner row tagged 'owner' and, below it, a member row reading 'name · email (v1.0 only, until <date>)' with a Remove button on the right.
Remove on a granted row takes the access away again. When everyone in your organization already has access, the lower list is replaced by a line saying so.
A key for someone outside the organization
Copy access key, at the bottom of the dialog, puts a key on your clipboard for someone your organization has no way of naming. Whoever redeems it gets access, and the key stops working the moment it is used. The log records that it was copied.
The PROJECT ACCESS dialog with the mouse over the Copy access key button so its tooltip is visible. If the log strip can be in the same frame, include the line 'Access key for <project> copied. It stops working the moment someone uses it.'
- —Owner only. Only the project's owner can mint one. An organization admin pressing the button gets the server's refusal in the dialog, because handing out keys to someone else's project would re-grant it without the owner ever knowing.
- —One use. Redeeming the key replaces it in the same statement that grants the access, so two people pasting the same key at the same moment cannot both get in. The second is told the key is not valid and may already have been used.
- —The same key until it is used. Pressing the button again before anyone redeems it copies the key that already exists, not a second one.
- —It carries no terms. The Gives row governs Give access. A redeemed key adds the person as a full member, with no pinned version and no expiry.
Redeeming a key you were given
The recipient has to be signed in to Parametra. The key is redeemed once, and from then on the project is simply in their list.
- Open Open From Parametra and press the padlock button in the row of tools beside the search box — “Use an access key someone gave you”.sharing-access-keys-open-key-button.png
The top strip of the Open From Parametra dialog: the search box, the filter dropdown, and the padlock and refresh icon buttons beside it, with the mouse hovering the padlock so its tooltip 'Use an access key someone gave you' shows.
/docs-shots/blender/The padlock button in Open From Parametra opens the key dialog. - Paste the key into the box in USE AN ACCESS KEY and press Use key.sharing-access-keys-use-key-dialog.png
The USE AN ACCESS KEY dialog open, showing the line 'Paste the key the project's owner gave you.', the key field with a key pasted into it, and the Close and Use key buttons at the bottom right.
/docs-shots/blender/The USE AN ACCESS KEY dialog, with a key pasted and ready to use. - On success the dialog says you now have access to the project. Close it and open the project from the list, which has already been told to reload.
A key that has already been used is refused, and nothing about the key itself says whether it is still live. If a recipient reports that the key did not work, the owner presses Copy access key again and sends the new one.
What a pinned version means for them
Pinning a grant to one version gives that person a snapshot and nothing else. The server enforces it on the way out, on every request for the project's files.
- —They see only that version. If they ask for no version in particular the server substitutes the pinned one; if they ask for a different one it refuses, with a line saying their access to this project is limited to that version.
- —If the pinned version is not the latest, the downloaded folder is marked as a snapshot and is read-only. Sync refuses it, saying the folder is showing that version and to open the latest version to make changes.
- —They cannot cut a new version. The server refuses, because they were given one version to look at.
That is what you want when someone needs the state a decision was made against rather than the live project. When they need to work on it, give them every version instead.
Your city is not your .blend. Access is granted to the project on Parametra, and the recipient downloads it into their own Documents/iCity 2/<project> folder. See How iCity fits with Blender and Organizations.
The Discord is fastest for anything scene-specific. Email suits licensing, billing and anything needing a file attached.
Contact support →