Table of Contents |
---|
🛠️ Potential Solutions
Update the exist Enhance existing search input to accept and search by loyalty ID, and communicate with loyalty service to get the consumer information.
✅ Proposed Solution
...
Enhance the
...
existent search bar inside the home screen to accept the loyalty id.
...
For that, it can be added a new line
...
to indicate the new
...
type of data (loyalty id) and a new validation to the input that will expect the LoyaltyId(UUID) format.
...
...
Enhance admin app to consume the loyaltyId and communicate to loyalty API.
...
For that, it can be created a new method in AdminApp to communicate
...
with Intl Loyalty Middleware service. This method will receive the loyaltyId and country and will return the specific loyalty user attributes, cognitoID(User ID) and email.
Zenuml sequence macro lite | ||||||
---|---|---|---|---|---|---|
|
All this idea already validate in a POC.
Country Solution
To the above flow works, a new information is necessary. The Loyalty Service expect in all call, the country in ISO format be specified (ES, PT, UK, …). Current the Admin App doesn’t have a way to delivery this properly. After an AWS analyses, was found that majority of the users are roles admin, and this role follow this format: ISO country + “-admin”. Based on this, is possible ready this information in the search page, split this to get the country code and send with the loyaltyId, making possible all the flow without any other configuration or creation (except the code mentioned in this document).
This idea is validated in this POC
How to get input data?
Since loyaltyId information are stored in distributed tables per country. Loyalty Middleware API requires country as part of the inputs. For that, proposed solution intends to pass the operator country using the following logic. Go through operators user groups and check by the <country>-admin groups.
...
Based on that, admin-app needs to provide this country as part of the inputs.
What if there are more than 1 country?
Then admin-app needs execute one query per country and stop the search once it finds a customer. E.g.: In Iberia region (euw3) there are only 2 countries ( Portugal and Spain). Since it’s a support tool with few operators, no issues with performance is expected.
Expand | ||
---|---|---|
| ||
Schemas/Customer
queries/customersCreate a new query inside the customers queries hooks/use-universal-searchCreate a use query for consume the customerByLoyaltyId Add on the map section the new query universal-search/searchInstructionsAdd new descriptions to this list for loyalty id The text for loyaltyId already exist in Lokalize, avoiding the necessity of create a new string text. |
⚠️Potential Challenges
Was made a POC to map all the challenges and no one appear.Not applicable
💰 Cost
No additional cost will be necessary.Not applicable
🎛️ Configuration
No configuration will be necessaryOperators needs to be assigned to <country>-admin user groups.
📈 Metrics
Note |
---|
To be defined by Design/Data Team. |
...