Acceso al portal: permisos y colaboración para clientes
Un cliente que inicia sesión en tu portal de Experience Cloud solo puede pagar si Salesforce le permite abrir las pantallas de REDA Pay y leer los registros que están detrás. Deben estar en su lugar cuatro cosas, y cada una responde a una pregunta distinta:
| Pregunta | La responde |
|---|---|
| ¿Este tipo de usuario puede abrir las pantallas y los objetos de REDA Pay? | El conjunto de permisos REDA Pay - Community User, o los mismos ajustes en el perfil del portal |
| ¿Qué Pay Orders, Pay Customers y Pay Methods puede ver? | Un conjunto de colaboración: solo los suyos |
| ¿Puede leer los Pay Profiles y las Processing Accounts que necesita la pantalla? | Reglas de colaboración o el acceso externo predeterminado, según la licencia |
| ¿Puede entrar al sitio? | La membresía de su perfil en el sitio |
Si falta cualquiera de ellas, el cliente ve un paso vacío, un error o un bucle de inicio de sesión. Este artículo configura las cuatro y luego las prueba como un cliente real. Las páginas en sí se explican en Permitir que los clientes paguen en tu portal.
- Tu sitio de Experience Cloud existe y los clientes pueden iniciar sesión en él.
- Cada usuario del portal está vinculado a un contacto (o, si los pagos pertenecen a la empresa del cliente, a una cuenta mediante ese contacto).
- Eres administrador de Salesforce y puedes editar perfiles, la configuración de colaboración y el sitio.
Paso 1: averiguar qué licencia tienen tus usuarios del portal
Salesforce comparte registros con los usuarios del portal de dos maneras distintas según la licencia, así que compruébala primero. Abre Configuración → Usuarios → Usuarios, haz clic en un usuario del portal, haz clic en su perfil y lee Licencia de usuario.
| Licencia de usuario | Tipo | Qué significa para REDA Pay |
|---|---|---|
| Customer Community o Customer Community Login | Gran volumen | Las reglas de colaboración no llegan a estos usuarios. Usa el conjunto de colaboración para sus propios registros y el acceso externo predeterminado para los registros de configuración (paso 4, ruta B) |
| Customer Community Plus, Customer Community Plus Login, Partner Community | Basada en funciones | Las reglas de colaboración llegan a estos usuarios. Usa el conjunto de colaboración para sus propios registros y reglas de colaboración para los registros de configuración (paso 4, ruta A) |
Si tu portal combina licencias, configura las dos rutas.
Paso 2: dar a los usuarios del portal acceso a los objetos y pantallas de REDA Pay
Elige una de dos formas equivalentes. Ambas dan exactamente el mismo acceso.
Opción A: asignar el conjunto de permisos (recomendado). Asigna REDA Pay - Community User a cada usuario del portal que paga: Configuración → Conjuntos de permisos → REDA Pay - Community User → Gestionar asignaciones → Agregar asignación. En un portal grande, agrégalo a un grupo de conjuntos de permisos que tus usuarios del portal ya reciban, o asígnalo de forma masiva con tu proceso habitual de alta de usuarios. Las actualizaciones de REDA Pay mantienen al día el conjunto, por eso es la opción recomendada.
Opción B: poner los mismos ajustes en el perfil del portal. Algunas organizaciones gestionan el acceso al portal solo con perfiles. En ese caso, edita cada perfil del portal que paga y dale lo que contiene el conjunto de permisos:
| En el perfil | Concede |
|---|---|
| Configuración de objetos: Pay Customer, Pay Method | Lectura, creación, edición |
| Configuración de objetos: Pay Order, Pay Transaction, Pay Profile, Processing Account, Fee Setup | Lectura |
| La seguridad a nivel de campo de esos objetos | El mismo acceso a campos que el conjunto de permisos: abre REDA Pay - Community User → Configuración de objetos y replica cada objeto |
| Acceso a clases de Apex activado | rpay.NewPayOrderController y rpay.NewPayMethodController |
| El acceso a tipos de metadatos personalizados (Enabled Custom Metadata Type Access) | REDA Pay Process Config y REDA Pay Setup |
En la interfaz de perfil mejorada, estas dos últimas secciones se llaman Acceso a clase de Apex y Tipos de metadatos personalizados.
El conjunto de permisos del paquete no concede eliminación, Ver todo ni Modificar todo en ningún objeto de REDA Pay; tampoco los agregues en el perfil.
Lo que concede el conjunto de permisos. Si usas perfiles, copia exactamente esto.
Paso 3: crear el conjunto de colaboración: cada cliente ve solo sus propios registros
El acceso a objetos dice que un cliente puede leer Pay Orders; no dice cuáles. Sin un conjunto de colaboración no ve ninguna, porque los registros de REDA Pay son privados para los usuarios externos de forma predeterminada. El conjunto de colaboración da acceso a los registros vinculados al propio contacto del cliente.
- Abre Configuración → Experiencias digitales → Configuración (Digital Experiences → Settings), baja hasta Conjuntos de colaboración (Sharing Sets) y haz clic en Nuevo.
- Ingresa una Etiqueta, por ejemplo REDA Pay - Customer Records.
- En la sección de perfiles, agrega todos los perfiles del portal cuyos usuarios pagan.
-
En Configurar acceso (Configure Access), agrega Pay Customer, Pay Method y Pay Order. Para cada uno, haz clic en Configuración (Set Up) y elige:
- Usuario (User): Contact
- Objeto de destino (Target Object): Contact
- Nivel de acceso: Lectura/escritura
- Haz clic en Guardar.
Las Pay Transactions y los Fee Setups no necesitan entrada: heredan el acceso de su Pay Order y de su Processing Account.
Si tus páginas del portal identifican al cliente por la cuenta (el ajuste Portal Record Identifier con el valor User-Account; consulta Permitir que los clientes paguen en tu portal), REDA Pay vincula los registros a la cuenta, así que asigna Usuario (User): Account al campo Account de cada objeto. Así, todos los usuarios de esa empresa ven los pagos de la empresa.
El conjunto de colaboración es lo que convierte "Pay Orders" en "mis Pay Orders".
Paso 4: permitir que los clientes lean los Pay Profiles y las Processing Accounts activos
La pantalla de pago lee el Pay Profile y la Processing Account para saber qué métodos se permiten, qué comisiones se aplican y cómo mostrar la marca de la página. Estos registros no pertenecen a ningún cliente, así que el conjunto de colaboración no puede cubrirlos.
Ruta A: licencias basadas en funciones (Customer Community Plus, Partner): dos reglas de colaboración. En Configuración → Configuración de colaboración, en Pay Profile reglas de colaboración, haz clic en Nuevo y crea:
| Ajuste | Valor |
|---|---|
| Etiqueta | Active Pay Profiles for portal users |
| Tipo de regla | Basada en criterios |
| Criterio | Is Active igual a True |
| En colaboración con | El grupo All Customer Portal Users (todos los usuarios del portal de clientes) |
| Nivel de acceso | Sólo lectura |
Luego lo mismo en Processing Account reglas de colaboración: Is Active igual a True, compartido con All Customer Portal Users (todos los usuarios del portal de clientes), Sólo lectura.
Ruta B: licencias de gran volumen (Customer Community, Customer Community Login): acceso externo predeterminado. Las reglas de colaboración no pueden incluir usuarios de gran volumen, así que abre los dos objetos a los usuarios externos. En Configuración → Configuración de colaboración, haz clic en Modificar en Valores predeterminados de toda la organización (en algunas organizaciones esta sección aparece con otro nombre, Default Sharing Settings en inglés) y define Acceso externo predeterminado como Sólo lectura pública para Pay Profile y Processing Account. Deja Pay Order, Pay Customer y Pay Method en Privado: de esos se encarga el conjunto de colaboración.
Con la ruta B, los usuarios externos pueden leer todos los registros de Pay Profile y Processing Account, activos o no. Las pantallas ofrecen solo los activos, y los identificadores de estos registros están cifrados; los datos de tarjetas y cuentas bancarias nunca se guardan en ellos.
Ruta A: los usuarios del portal con licencias basadas en funciones leen los Pay Profiles activos mediante una regla de colaboración.
La ruta B cambia la columna de acceso externo predeterminado solo para Pay Profile y Processing Account.
Paso 5: comprobar que el perfil es miembro del sitio
Los usuarios solo pueden iniciar sesión en un sitio al que pertenece su perfil. En Configuración → Experiencias digitales → Todos los sitios (Digital Experiences → All Sites), haz clic en Espacios de trabajo (Workspaces) junto a tu sitio, abre Administración → Miembros (Administration → Members) y comprueba que cada perfil del portal del paso 3 esté entre los perfiles seleccionados. Si no está, agrégalo y haz clic en Guardar.
Paso 6: probar como un cliente real
Un administrador ve todos los registros, así que probar como tú mismo no demuestra nada. Prueba como usuario del portal:
- Abre el contacto de un cliente de prueba y elige Iniciar sesión en Experience como usuario (Log in to Experience as User).
- Abre la página de pago. Si existen varios Pay Profiles activos, "Select Pay Profile" los muestra; elige uno.
- La pantalla de pago se abre con la marca de la cuenta y los métodos guardados del cliente.
- Ingresa un importe, pulsa Pay y cancela el resumen.
- Abre la página de historial de pagos del cliente si tienes una: solo aparecen las Pay Orders de ese cliente.
Síntomas y qué falta
| Qué ve el cliente | Lo que suele faltar | Solución |
|---|---|---|
| Una página de inicio de sesión, o "Insufficient Privileges" en el sitio | La membresía en el sitio, o la página requiere un perfil que no tiene | Paso 5 |
| Un error al cargar la página de pago | El acceso a las clases de Apex | Paso 2: el conjunto de permisos, o las dos clases en el perfil |
| "Select Pay Profile" sin opciones, o sin cuenta de procesamiento | El acceso a los registros de configuración | Paso 4: la ruta de su licencia |
| "Bad Request. Parent record not found." o una pantalla vacía | Sus propios registros no están compartidos | Paso 3: el conjunto de colaboración, en el campo correcto |
| El historial de pagos no muestra nada | Al conjunto de colaboración le falta Pay Order, o el campo es incorrecto | Paso 3 |
| Funciona para una licencia y no para otra | Solo se configuró una ruta | Paso 4: configura ambas |
Errores que debes evitar
| Error | Qué ocurre | Solución |
|---|---|---|
| Crear reglas de colaboración para un portal de gran volumen | Nada cambia para los clientes | Usa la ruta B, el acceso externo predeterminado |
| Abrir Pay Order o Pay Customer como Sólo lectura pública | Todos los clientes podrían leer todos los pagos | Mantenlos en Privado; el conjunto de colaboración da a cada cliente los suyos |
| Asignar REDA Pay - User a los usuarios del portal | Es un conjunto para el personal interno y da mucho más de lo que necesitan los clientes | Usa REDA Pay - Community User |
| Asignar el conjunto de colaboración a Lead | Los usuarios del portal nunca son prospectos; no se comparte nada | Asigna User: Contact a Contact (o User: Account a Account) |
| Agregar más tarde un perfil del portal y olvidar el conjunto de colaboración | Los clientes nuevos ven pantallas vacías | Agrega el perfil al conjunto de colaboración y a los miembros del sitio |
Preguntas frecuentes
No. El conjunto de colaboración comparte solo los registros vinculados al propio contacto (o cuenta) del usuario, y por lo demás las Pay Orders, los Pay Customers y los Pay Methods siguen siendo privados para los usuarios externos.
Revisa Configuración → Paquetes instalados → REDA Pay: si Licencias permitidas indica Ilimitadas, no hace falta asignar nada; si no, asigna una licencia a cada usuario del portal antes del conjunto de permisos.
No. Los enlaces de pago los abren visitantes anónimos mediante el usuario invitado de tu sitio público, que tiene su propia configuración; consulta Acceso de invitados para enlaces de pago: permisos y colaboración.
Qué sigue
- Permitir que los clientes paguen en tu portal: crear las páginas de pago.
- Pago automático en el portal: pagos recurrentes de los clientes: qué pueden programar los clientes.
- Quién puede hacer qué: conjuntos de permisos: los siete conjuntos de permisos de REDA Pay.