Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This PRD addresses various scenarios that call for a need to merge two accounts. 

There are multiple instances in which this may be required. The JTBD section below lists the scenarios that are covered in this PRD 


Introduction

JTBD

  • Jobs To Be Done: 

    A user has carried out self sign up (onto the custodian org). The state then initiates formal on boarding of users (via SSO, or API based account creation).

    1. If the state attempts to create  an account with the same identifier that the user had provided to Diskha during self sign up, the account creation process will fail due to duplication of the identifier. This prevents the user from being granted a validated state account.

    2. If the state user creation process uses a different identifier for the user, the account gets created on the state tenant, and the user ends up with two different accounts, one on the state tenant, and one on the custodian org. This could lead to further confusion

A user may carry out some activity using their self signed up account (consume a course, etc.). There is a need for such user activity to reflect in the state tenant account of the user, so that it can reflect in state reports. In such a scenario, the usage data from the self signed up account has to be merged into the state tenant account. 

Also, users often realise that they don't need two accounts, and want to have just one account - this means merging accounts to ensure no history is lost.


  • User Personas: Users who explore/ sign up on Diksha before a formal state on boarding approach is announced. Such users will be constrained from creating an account in the state tenant if they already have a self signed up account with their primary identifier.
  • System or Environment: 

Requirement Specifications

This section consists of requirement specifications for specific use cases in the User JTBD. The requirements for each use case are elaborated in detail through sub-sections for:

  • Use case overview
  • Overall process workflow
  • Associated user stories 
  • Non-functional requirements
  • Localization requirements  
  • Telemetry requirements
  • Dependencies
  • Impact on other products
  • Impact on existing data  

<Use Case 1> Overview

<Use Case 1 Overall Process Workflow>


<Use Case 1 - User Story 1> Overview

<Main Scenario>

Srl. No.User ActionExpected Result






<Alternate Scenario 1>

Srl. No.User ActionExpected Result






Exception Scenarios

Srl. No.Error / ExceptionExpected Handling






Wireframes

For Future Release

JIRA Ticket ID

<Use Case 1 - User Story 2> Overview

Localization Requirements

UI ElementDescriptionLanguage(s)/ Locales Required



Telemetry Requirements

Event NameDescriptionPurpose

Non-Functional Requirements

Performance / Responsiveness RequirementsLoad/Volume RequirementsSecurity / Privacy Requirements



Impact on other Products/Solutions

Product/Solution ImpactedImpact Description


Impact on Existing Users/Data 

User/Data ImpactedImpact Description


Key Metrics

Srl. No.MetricPurpose of Metric




  • No labels