In questa pagina: Scopri i ruoli fedeltà predefiniti, le autorizzazioni disponibili, le funzionalità dei ruoli, l’ambito sandbox e come assegnare ruoli agli utenti.
Panoramica overview
La fedeltà di Adobe Journey Optimizer utilizza il controllo degli accessi basato sul ruolo di Adobe Admin Console per gestire l’accesso degli utenti.
L’assegnazione del ruolo è necessaria prima che gli utenti possano eseguire operazioni di fidelizzazione. Agli utenti senza un ruolo assegnato viene negato l’accesso agli endpoint del servizio fedeltà. Prima di effettuare l’onboarding degli utenti in Fedeltà, assegna un ruolo appropriato a ciascun utente che utilizzerà il servizio.
I ruoli possono essere assegnati direttamente a singoli utenti o tramite gruppi di utenti. Scopri come assegnare ruoli agli utenti.
Ruoli consigliati recommended-roles
La fidelizzazione fornisce tre ruoli predefiniti preconfigurati per la sandbox Prod. I nuovi clienti possono utilizzare questi ruoli così come sono.
Amministratore fedeltà loyalty-administrator
Il ruolo di Amministratore fedeltà fornisce accesso amministrativo completo a tutte le funzionalità di fedeltà: problemi, configurazione, catalogo prodotti e approfondimenti.
Professionista fedeltà loyalty-practitioner
Il ruolo Professionista fedeltà è progettato per i proprietari aziendali che gestiscono l’intero ciclo di vita della sfida e modificano la configurazione principale. La configurazione dei premi, la configurazione degli eventi e l’accesso al catalogo dei prodotti sono di sola lettura. L’eliminazione e le scritture di configurazione avanzate non sono consentite.
Analista fedeltà loyalty-analyst
Il ruolo Analista fedeltà fornisce accesso in sola lettura a sfide, catalogo dei prodotti e approfondimenti. Utilizza questo ruolo a scopo di reporting e controllo.
Funzionalità ruolo role-capabilities
Ambito ruolo predefinito default-role-scope
Per concedere agli utenti l’accesso a una sandbox non di produzione, ad esempio una sandbox di staging o di sviluppo, crea un ruolo personalizzato per tale sandbox e assegna le stesse autorizzazioni del ruolo predefinito corrispondente.
Autorizzazioni disponibili per i ruoli personalizzati custom-role-permissions
Quando crei un ruolo personalizzato per una sandbox non di produzione, seleziona una delle autorizzazioni seguenti. Per replicare un ruolo predefinito, consulta le autorizzazioni elencate nella sezione relativa al ruolo precedente.
Assegna ruoli agli utenti assign-roles
Adobe Admin Console supporta due approcci per l’associazione di ruoli agli utenti.
Assegnare gli utenti direttamente a un ruolo assign-users-directly
Aggiungere singoli utenti direttamente a un ruolo. Questo approccio è ideale per piccoli team o assegnazioni una tantum.
Utilizzare i gruppi di utenti use-user-groups
Crea un gruppo di utenti, quindi assegna al gruppo sia utenti che un ruolo. Questo approccio è ideale per gestire l’accesso per reparto o funzione su larga scala.
Per istruzioni dettagliate sulla gestione di ruoli, gruppi e utenti, consulta la documentazione sul controllo degli accessi a Adobe Journey Optimizer:
Risoluzione dei problemi di accesso troubleshooting
Se un utente non può accedere a Sfide fedeltà o a una funzione correlata, verifica quanto segue:
- L’utente viene assegnato a un ruolo Fedeltà.
- Il ruolo include la sandbox in cui è abilitata l’opzione Sfide di fedeltà.
- Il ruolo include l’autorizzazione necessaria per l’azione che l’utente sta tentando di eseguire.
- Per le sandbox non di produzione, è stato creato un ruolo personalizzato per tale sandbox.
- L’organizzazione e la sandbox sono abilitate per le sfide di fedeltà.
Se i problemi di accesso persistono dopo l’aggiornamento delle autorizzazioni, contatta il rappresentante Adobe.
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page explains the default Loyalty Challenges roles, available permissions for custom roles, role capabilities, sandbox scope, how to assign roles to users, and how to troubleshoot access issues.
Intents:
- Identify the three default Loyalty roles and what each one permits.
- Compare role capabilities across Challenges, primary organization configuration, reward configuration, event configuration, product catalog, and insights.
- Understand that default roles are scoped to the Prod sandbox and create a custom role for other sandboxes.
- Select permissions when building a custom role for a non-Prod sandbox.
- Assign roles to users directly or through user groups.
- Troubleshoot why a user cannot access Loyalty Challenges or a related feature.
Glossary:
- Loyalty Administrator: role providing full administrative access to all Loyalty features: challenges, configuration, product catalog, and insights (product-specific)
- Loyalty Practitioner: role for business owners who manage the full challenge lifecycle and edit primary configuration; reward configuration, event configuration, and product catalog access are read-only; deletion and advanced configuration writes are not permitted (product-specific)
- Loyalty Analyst: role providing read-only access to challenges, product catalog, and insights, for reporting and audit purposes (product-specific)
- Manage Loyalty Advanced Configuration: permission to manage reward endpoints and event transformation settings, including read/write access to sensitive credential values (product-specific)
- Develop Loyalty Challenges: custom-role permission to create and edit challenges via API; delete and lifecycle actions are not permitted (product-specific)
Guardrails:
- Role assignment is required before users can perform Loyalty operations.
- Users without an assigned role are denied access to Loyalty service endpoints.
- Default Loyalty roles (Loyalty Administrator, Loyalty Practitioner, Loyalty Analyst) are scoped to the Prod sandbox only.
- Primary organization configuration deletion is permitted for Loyalty Administrator only, not for Loyalty Practitioner.
- Reward configuration write access or access to sensitive values, and event configuration write access, are permitted for Loyalty Administrator only.
- Product catalog import or edit, and insights write or KPI configuration update, are permitted for Loyalty Administrator only.
- Loyalty Analyst has no create, edit, delete, publish, unpublish, archive, or journey-generation-trigger access to Challenges.
Prerequisites and permissions:
- To grant users access to a non-Prod sandbox (such as staging or development), create a custom role for that sandbox and assign the same permissions as the corresponding default role.
- Only Product administrators and System administrators can manage users, groups, and roles.
Terminology:
- Canonical names: Loyalty Administrator, Loyalty Practitioner, Loyalty Analyst — the three default Loyalty roles.
- Do not confuse: “Manage Loyalty Primary Configuration” (create, edit, and delete) ≠ “Configure Loyalty Primary Configuration” (create and edit; deletion is not permitted).
- Do not confuse: “Manage Loyalty Challenges” (full challenge operations including delete, publish, unpublish, archive, and trigger journey generation) ≠ “Develop Loyalty Challenges” (create and edit via API only; delete and lifecycle actions are not permitted) ≠ “View Loyalty Challenges” (view only).
- Do not confuse: “Manage Loyalty Insights” (view, update KPI configuration, trigger the insights pipeline) ≠ “Develop Loyalty Insights” (view insights data and update insight cards) ≠ “View Loyalty Insights” (view AI-generated insight cards, health vitals, and challenge performance data only).
FAQ:
- Q: What are the three default Loyalty roles? — Loyalty Administrator, Loyalty Practitioner, and Loyalty Analyst.
- Q: What sandbox are default Loyalty roles scoped to? — The Prod sandbox only.
- Q: How do I give a user access to a non-Prod sandbox? — Create a custom role for that sandbox and assign the same permissions as the corresponding default role.
- Q: Can a Loyalty Practitioner delete primary organization configuration? — No, deletion is not permitted for Loyalty Practitioner.
- Q: Who can manage users, groups, and roles? — Only Product administrators and System administrators.
- Q: What access does a Loyalty Analyst have? — Read-only access to challenges, product catalog, and insights, for reporting and audit purposes.
Troubleshooting:
- Symptom: user cannot access Loyalty Challenges or a related feature. Checks: the user is assigned to a Loyalty role; the role includes the sandbox where Loyalty Challenges is enabled; the role includes the permission required for the action; for non-Prod sandboxes, a custom role has been created for that sandbox; the organization and sandbox are enabled for Loyalty Challenges. If issues persist after permissions are updated, contact your Adobe representative.
Best practices:
- Assign users directly to a role for small teams or one-off assignments.
- Use user groups to manage access by department or function at scale.
Related pages:
- For step-by-step instructions on managing roles, groups, and users: Manage users and roles (administration/permissions.md)
- For step-by-step instructions on managing roles, groups, and users: Built-in permissions (administration/ootb-permissions.md)
Personas:
- admin: Can assign a role to users directly, or create a user group and assign both users and a role to the group. Can create a custom role for a non-Prod sandbox and assign it the same permissions as the corresponding default role. The page states that default Loyalty roles are scoped to the Prod sandbox only. Where: “Assign roles to users”.
Onboarding:
- Level: Intermediate
- First minimal step: Assign an appropriate role to each user who will use the service.
- Success check: The assigned user can perform Loyalty operations and is not denied access to Loyalty service endpoints.
- Next: For step-by-step instructions for managing roles, groups, and users: Manage users and roles (administration/permissions.md); For built-in permissions details for managing roles, groups, and users: Built-in Roles (administration/ootb-permissions.md)