Añadir roles de usuario y permisos reales
Otorgar a propietarios, personal y clientes diferentes páginas, acciones y acceso, aplicado sobre la información almacenada.
Cuándo usarlo
Cuando el inicio de sesión ya funciona pero los propietarios, el personal y los clientes necesitan diferentes páginas, acciones y acceso a la información almacenada.
Antes de empezar
- Registro e inicio de sesión en funcionamiento. Utilice primero el asistente de autenticación si aún no existen cuentas.
- Una lista escrita de los roles que realmente necesita. Comience con menos roles y agregue otro solo cuando sus permisos sean genuinamente diferentes.
- Una matriz de permisos simple que muestre lo que cada rol puede ver, crear, cambiar y eliminar.
- Cuentas de prueba seguras por separado para cada rol, además de una ventana del navegador cerrada sesión.
- Una decisión sobre quién puede asignar o cambiar roles. Esto normalmente debería limitarse al propietario o a un administrador con mucha confianza.
El prompt
Estos prompts funcionan mejor en inglés — pégalos tal como están, incluso en páginas traducidas.
Add user roles and permissions to this existing app. Login already works. The roles are [ROLE ONE], [ROLE TWO] and [ROLE THREE]. Use these descriptions: [ROLE ONE CAN SEE AND DO], [ROLE TWO CAN SEE AND DO], and [ROLE THREE CAN SEE AND DO]. Before changing anything, show me a plain-language matrix with the roles down one side and the important pages, information and actions across the top. Mark what each role can view, create, change and delete. Include logged-out visitors. Flag any unclear or conflicting instruction instead of guessing. After I approve the matrix, enforce it on both the screens and the stored information. Hiding a menu item is not protection. If someone types a private page address directly or changes an item number in the address, the app must still refuse access to anything outside that person's permission. Use the safest default when a rule is missing: deny the action and show a calm message. A [CUSTOMER ROLE] may see and change only [THEIR OWN INFORMATION]. A [STAFF ROLE] may see and change [ASSIGNED OR SHARED INFORMATION]. A [OWNER ROLE] may manage [OWNER-ONLY AREAS]. Adjust these examples to match my approved matrix. Add an owner-only user management screen where [AUTHORIZED ROLE] can view a person's current role and change it. Users must never choose a more powerful role for themselves through sign-up, profile editing or a changed page address. Keep a small history showing who changed a role, whose role changed, the old role, the new role and the time. Do not confuse live app roles with builder access. Staff who use the finished app should not automatically gain access to the builder, project settings, private connection keys or deployment controls. Test with one account for every role and one logged-out window. Try the normal navigation, direct page addresses, viewing another person's record, changing allowed information and attempting one forbidden action. Do not use real customer accounts or data. Keep the existing design and make denied-access messages clear rather than frightening. Finish with the approved matrix, the test results and anything that remains broader than I requested.
¿Ya estás creando? Pega esto en tu proyecto. ¿Empiezas de cero? Abre una cuenta gratuita en un creador compatible a continuación.
Créalo en
Qué crea esto
- Una matriz de permisos en lenguaje sencillo para cada rol
- Páginas protegidas e información almacenada basada en esa matriz
- Una pantalla exclusiva para el propietario para asignar roles
- Protección contra la autopromoción y el acceso mediante direcciones directas
- Un pequeño historial de cambios de roles
- Resultados de las pruebas de cada rol y de un visitante no registrado
Comprueba que funcionó
Pega el prompt, espera a que termine la construcción y luego confirma esto — en lenguaje sencillo, sin comprobaciones técnicas:
- Cada cuenta de prueba solo ve las páginas y acciones destinadas a su rol
- Una cuenta de cliente no puede ver la información de otro cliente
- Una cuenta de personal puede completar su trabajo permitido pero no puede abrir la configuración exclusiva del propietario
- Escribir una dirección de página prohibida directamente muestra un mensaje de acceso en lugar de contenido privado
- Un usuario normal no puede asignarse a sí mismo un rol más poderoso
- El propietario autorizado puede cambiar un rol de prueba y ver un historial legible de ese cambio
- Cerrar la sesión elimina el acceso inmediatamente
¿Falta algo? Es normal — pídelo en un mensaje corto de seguimiento en vez de volver a ejecutar todo el prompt.
Siguientes pasos
Añadir invitaciones de personal
Cuando las reglas de roles funcionan y el propietario necesita una forma segura de añadir miembros al equipo
Add an owner-only invitation flow for [STAFF ROLE]. The owner enters [STAFF EMAIL] and chooses from [ALLOWED STAFF ROLES]. The invited person sets up their own login and receives only the selected live app role. Do not give them access to the builder or project settings.
Sabrás que funcionó cuando: Una cuenta de prueba invitada se une con el rol de personal elegido y no puede entrar en áreas exclusivas del propietario ni en el constructor.
Limitar al personal a los registros asignados
Cuando el personal debe trabajar solo con sus propios clientes, ubicaciones o tareas
Change [STAFF ROLE] access so each staff member can view and update only records assigned to them through [ASSIGNMENT FIELD OR RULE]. Owners may still view all records. Test with two staff accounts and confirm neither can open the other's assigned record directly.
Sabrás que funcionó cuando: Cada cuenta de prueba del personal ve solo su trabajo asignado, mientras que el propietario sigue viendo la lista completa.
Auditar permisos después de una nueva funcionalidad
Siempre que añada una página, un tipo de dato o una acción de administrador
Update the existing permission matrix for [NEW FEATURE]. Show what logged-out visitors and every current role can view, create, change and delete. Apply the narrowest approved rules, then repeat one allowed and one forbidden test for each affected role.
Sabrás que funcionó cuando: La nueva funcionalidad aparece en la matriz y sigue el mismo sistema de permisos probado que el resto de la aplicación.
Ojo con
- Los roles de aplicación y los roles de constructor son diferentes. Alguien que gestiona clientes dentro de la aplicación terminada no necesita automáticamente permiso para editar la propia aplicación.
- Los botones ocultos no son control de acceso. Pruebe las direcciones de página directas y el registro de otra persona; la información almacenada debe rechazar la solicitud incluso cuando el menú la oculte.
- Demasiados roles se vuelven imposibles de gestionar. Comience con propietario, personal y cliente a menos que un cuarto rol tenga responsabilidades claramente diferentes.
- Los cambios de permisos pueden afectar a los usuarios reales de inmediato. Pruebe con cuentas de muestra y revise la matriz antes de aplicar cambios a una aplicación en vivo.
- Un rol de personal demasiado amplio puede exponer más de lo esperado. Si el personal debe ver solo clientes o ubicaciones asignadas, establezca esa regla explícitamente y realice pruebas con dos cuentas de personal.
Notas por plataforma
<ul><li><strong>Base44:</strong> Base44 incluye roles de aplicación en vivo y reglas de acceso a datos, y puede crear roles adicionales más allá de sus valores predeterminados. Los colaboradores del constructor son distintos a los usuarios de la aplicación, así que no convierta a un usuario del personal en colaborador a menos que realmente necesite editar la aplicación.</li><li><strong>Lovable:</strong> Lovable puede crear acceso basado en roles con Lovable Cloud o almacenamiento Supabase conectado. Solicite protección en la información almacenada, no solo en las páginas visibles, y pruebe cada rol después de publicar.</li><li><strong>v0:</strong> v0 necesita un inicio de sesión y un servicio de datos conectados para obtener permisos reales. Puede construir las pantallas y las comprobaciones privadas, pero el proveedor de almacenamiento exacto debe hacer cumplir quién puede leer o cambiar la información de cada persona.</li></ul>
Gasta menos créditos
Toda plataforma te cobra por el trabajo que hace su IA — así que el hábito más barato es pensar antes de construir. Estas seis reglas eliminan la mayor parte del desperdicio, elijas la plataforma que elijas.
- Planifica primero en un chat gratuito. Esboza todo en ChatGPT, Claude o Gemini — páginas, funciones, qué recoge cada formulario, cómo debe verse. Pensar allí es gratis; pensar dentro de un builder se factura.
- Empieza con un prompt escrito, no con una frase. "Hazme una web" es la frase más cara al construir con IA. Un primer prompt completo — como los de este sitio — ahorra decenas de rondas de corrección.
- No seas perezoso con los detalles. Cada detalle que omites vuelve como una corrección que pagas. Nombre del negocio, colores, cada página, cada campo del formulario, qué pasa tras el envío — ponlo todo en el primer prompt.
- Después, un cambio por mensaje. "Arregla la cabecera, y el formulario, y los colores" produce un enredo que cuesta más deshacer de lo que ahorró.
- ¿Atascado? Deja de parchear. Si la misma corrección falla unas tres veces, no envíes una cuarta — describe el estado final deseado de toda la sección en un mensaje nuevo.
- Empieza gratis. Mejora el plan cuando necesites más. Usa la cuota gratuita para crear y explorar tu primera versión. Mejora el plan cuando necesites más uso o funciones de pago, y revisa el coste de los servicios conectados antes del lanzamiento.
Los prompts de esta página están escritos para hacer casi todo este trabajo por ti — de eso se trata.
Lee la guía completaPlaybooks relacionados
Prompts relacionados
Revisado el: 2026-07-27