Cómo usar
- Copia el comando y revisa el paquete antes de instalarlo en tu entorno de agente.
- Consulta las herramientas, credenciales y entornos necesarios en el documento original.
- Describe las entradas y el resultado deseado; contrasta la salida con las fuentes.
npx skills add https://github.com/port-labs/port-skills --skill port-permissionsAntes de empezar
- La instalación no incluye suscripción al modelo, cuota API ni permisos sobre tus archivos.
- Las estrellas e instalaciones reflejan actividad, no una prueba independiente de calidad o seguridad.
Contenido del repositorio de origen con títulos, ejemplos, código, tablas, enlaces e imágenes preservados.
Port permissions
Port's RBAC shows up in two independent places that reuse the same roles/users/teams shape: context lake entities (a blueprint's read, register, update, unregister) and pages/dashboards (read, update). This skill covers both, plus the roles and ownership model that backs them.
Permissions on a workflow's own SELF_SERVE_TRIGGER node are a separate, simpler mechanism owned by the port-workflows skill, see its permissions reference instead of this one.
Prerequisites
- Go over the
port-getting-startedskill first if this is your first time
working with Port.
- The blueprint or page whose permissions you're changing already exists.
- If Port's MCP server is connected, use
list_blueprintsto read current
blueprint definitions before editing, and simulate_blueprint_permissions to test a context lake permission change before applying it. There is no MCP tool that writes permissions directly, every step below applies changes through the raw API, UI, or Terraform. Search search_port_knowledge_sources for anything this skill doesn't cover.
How to configure it
- Know the two building blocks every permission type reuses: Port's
three roles (Admin, blueprint Moderator, Member) and the $team ownership meta-property that backs every ownedByTeam flag. See references/roles-and-ownership.md.
- Set context lake (blueprint/entity) permissions: who can
read,
register, update, or unregister entities of a blueprint, down to a single property or relation, a dynamic read policy, and the built-in permission simulator. See references/context-lake-permissions.md.
- Set page and dashboard permissions: who can view or edit a catalog
or dashboard page. See references/page-permissions.md.
- Setting permissions on a workflow trigger instead? That's a
different, simpler shape scoped to one SELF_SERVE_TRIGGER node, not this skill, use the port-workflows skill's permissions reference.
Steps 2 and 3 are independent, do whichever the task needs.
Examples
a blueprint's entities permissions combining role/user/team grants, ownedByTeam registration, and a dynamic read policy.
a PATCH body giving a team read access and restricting update to Admins.
Common pitfalls
| Symptom | Cause | Fix |
|---|---|---|
Set ownedByTeam and a dynamic read policy on the same scope, only one works | When entity owner permissions are configured, the dynamic read policy is ignored | Pick one: ownedByTeam for team-based access, policy for anything else |
Granular updateProperties grant has no effect | A global update permission is also set, global overrides granular | Remove the global update grant, or fold the property-level grant into it |
User can't register a new entity even though register allows their role | The entity also has a required property or relation they lack updateProperties/updateRelations access to | Grant edit access to every required field, not just the top-level register scope |
PATCHing page permissions removed a role's/user's/team's access unexpectedly | PATCH replaces each key you include entirely; omitting an existing member of that key removes them | Include the full desired list for every key you send, not just the ones you're adding |
| Terraform permission resource conflicts with UI edits | port_page_permissions fully owns the resource once applied | Manage a given page's permissions from one place, Terraform or the UI, not both |
Trying to add a dynamic queries/conditions policy to a workflow trigger | That shape belongs to Port's legacy, deprecated Actions & Automations permissions, not Workflows | Use the simpler policy (combinator/rules over user/userTeams/form context) documented in port-workflows' permissions reference instead |
Quick reference
- Three roles: Admin (everything), blueprint Moderator (everything on one
blueprint), Member (read + execute workflows by default).
- Context lake entity permission scopes:
read,register,unregister,
update, updateProperties.<property>, updateRelations.<relation>. Each takes roles/users/teams/ownedByTeam; read also takes a dynamic policy. API: GET/PATCH /v1/blueprints/{id}/permissions.
- Page permission scopes:
read,update. Each takes
roles/users/teams. API: PATCH /v1/pages/{id}/permissions.
- For a workflow's
SELF_SERVE_TRIGGERnode permissions (a different,
simpler shape scoped to one trigger), see the port-workflows skill's permissions reference instead of this one.
