Table of Contents |
---|
🛠️ Potential Solutions
Info |
---|
Note: this section should be short and sweet, documenting notes about different solutions that were considered during ideation. Can just be a link to a whiteboard for example. Expected outcome: one solution is chosen and documented in more detail under Proposed Solution. |
✅ Proposed Solution
Info |
---|
Description of the proposed solution. |
...
Info |
---|
List here potential challenges that have come across the opportunity definition or from the potential solutions so far. |
💰 Cost
Info |
---|
Describe any additional cost this solution may imply. |
🎛️ Configuration
Info |
---|
Include here any configuration required (Sanity, LaunchDarkly flags, etc.) required to enable the solution. |
📈 Metrics
...
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 highlight 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 customerId and email. With the customerId FE is already prepared to fetch customer related data as it does for other input searches.
Zenuml sequence macro lite | ||||||
---|---|---|---|---|---|---|
| ||||||
This idea is validated in this POC
How to get the input data?
Since loyaltyId information are stored in distributed tables per country. Loyalty Middleware API requires country as part of the inputs. E.g.: loyalty-es-users-plk-dev
For that, proposed solution intends to pass the operator country using the following logic:
Go through all operators user groups and check one-by-one 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
Not applicable
💰 Cost
Not applicable
🎛️ Configuration
Operators needs to be assigned to <country>-admin user groups.
📈 Metrics
Note |
---|
To be defined by Design/Data Team. |
🗓️ Delivery Plan
Info |
---|
Link to the task or list of all the tasks required to deliver the solution, along with its progress. |
🧑🚒 QA Plan
Info |
---|
Note |
To be defined by QA Team. |
⚠️ Call-outs
...
No call-outs