This refinement details the necessary changes for the search by phone to work in admin tool documented in Search customer by phone in Admin App .

Solution 1

Create a phone lookup record in the commit order workflow. This will make sure that we’ll be able to find the customer searching by his phone as long as he has included it on the order, or registered in his account (verified or not). There are three possible scenarios:

Scenario	Condition	Outcome
Delivery order	Phone number is mandatory to close the order	Creates record using the order’s phone number
Not delivery order but user has a phone added to his account	Phone number is not mandatory	Creates record using the user’s account phone number if it doesn’t exist already
Not delivery order and user hasn’t added a phone to his account	Phone number is not mandatory	Doesn’t create a record

Pros and cons

Pros

Uses existing lookup record structure
Search will work with both phone numbers included in the order or in the user account
Doesn’t require phone verification
Doesn’t require migration scripts, the search will work as long as the user has made one order after the feature release

Cons

A phone number can only be associated with a single customer, which will be the first one to inform the number on the platform
There isn’t a simple way to delete the link between an user and phone number recorded in a delivery order . One possibility is allowing customer support to remove the link via the support tool if it is outdated.

Implementation Proposal

The sequence diagram below represents one possible implementation of the solution where the responsibility of managing lookup records stay in the intl-users packages.

POC

The code below creates lookup records if they don’t exist when the order is committed.

intl-whitelabel-graphql/src/functions/graphql/resolvers/orders.ts

Mutation: {
   async commitOrder(...) {
   ...
    const savePhone = () => {
      const phoneNumber = delivery?.dropoff?.phoneNumber ?? contextUser.details.phoneNumber;
      const { cognitoId } = contextUser;
      if (phoneNumber && cognitoId) {
        providers.users.createPhoneRecord(cognitoId, phoneNumber);
      }
    };
 
    savePhone();
  }
}

intl-packages/src/user-lookup-by-phone/user-lookup-by-phone.ts

  class UserLookupByPhone {
    public async create({ cognitoId, phoneNumber }: { cognitoId: string; phoneNumber: string }) {
      const params = {
        ConditionExpression: INSERT_CONDITION_EXPRESSION,
        Item: {
          pk: `phone#${phoneNumber}`,
          pk2: `phone_user#${cognitoId}`,
          sk: 'v0_UserPhone',
          sk2: 'v0_UserPhoneLookUp',
        },
        TableName: this.tableName,
      };
  
      await this.executeWithRetry(DynamoMethods.put, params);
    }
    
    public async getByUserServiceLookup(
      phoneNumber: string,
    ): Promise<IUserLookupByPhone | undefined> {
      const dynamoSearch = {
        ExpressionAttributeValues: {
          ':pk': `phone#${phoneNumber}`,
          ':sk': 'v0_UserPhone',
        },
        KeyConditionExpression: 'pk = :pk AND begins_with(sk, :sk)',
        TableName: this.tableName,
      };
  
  
      const { Items } = await this.executeWithRetry(DynamoMethods.query, dynamoSearch);
      const Item = Items?.[0];
      return Item ? cast(Item, TUserLookupByPhone) : undefined;
    }
  }

Commit an order with delivery.dropoff.phoneNumber +222222
Validate record in database
Searching phone in support tool
Customer details

Solution 2

The solution 2 uses the exact same strategy of solution 1, the only difference is that it proposes to update the lookup record structure so that it can link multiple phone numbers to multiples customers. Below is an suggestion of the new record:

{
  pk: `phone_user#${cognitoId}`,
  pk2: `phone#${phoneNumber}`,
  sk: `createdAt#${createdAt}`,
  sk2: 'createdAt#${createdAt}',
}

With these changes the search by phone will return a list of customers instead of single one and avoid the problem of manual record deletion that solution 1 requires. However, the support tool front end will also have to be adapted so that customer support can choose which one they want to check given the list of customers associated with that phone number.

Pros and cons

Pros

Search will work with both phone numbers included in the order or in the user account
Doesn’t require phone verification
Doesn’t require migration scripts, the search will work as long as the user has made one order after the feature release
Allows the association of multiple phone numbers with multiple customers

Cons

Require the development of a new page in support tool front end to select which customer they want to check
Although very unlikely, there is a scenario where a single phone number is linked to many customers and this might make the process to finding the right one cumbersome

POC

For this POC I changed the getByUserServiceLookup to use the proposed structure:

intl-packages/src/user-lookup-by-phone/user-lookup-by-phone.ts

public async getByUserServiceLookup(
  phoneNumber: string,
): Promise<IUserLookupByPhone[] | undefined> {
  const dynamoSearch = {
    ExpressionAttributeValues: {
      ':pk2': `phone_lookup#${phoneNumber}`,
      ':sk2': 'createdAt#',
    },
    IndexName: 'brand-index-2',
    KeyConditionExpression: 'pk2 = :pk2 AND begins_with(sk2, :sk2)',
    TableName: this.tableName,
  };

  const { Items } = await this.executeWithRetry(DynamoMethods.query, dynamoSearch);
  return Items ? Items.map((item) => cast(item, TUserLookupByPhone)) : undefined;
}

And created 4 lookup records for 2 customers:

and was able to find the two customers when searching for the phone number +123123123:

Tech Refinement - search customer by phone (Admin tool)

Solution 1

Pros and cons

Implementation Proposal

POC

Solution 2

Pros and cons

POC