# Use cases
Below is a chart presenting group hierarchy to describe use cases on real structure.
### 
### Group limits
First account is created for the corporation during the process of adding the corporation. Second one can be added by the Issuer Admin. To be able to assign cards there must be a limit set to the highest group.
1. Issuer Admin creates account A for corporation.
2. Corporate Admin from Chief level group add limit for account A for Chief level group. Now only Corporate Admins from the Chief level group see this account.
3. Corporate Admin from Chief level group add limit for account A for Java group. Now Corporate Admins from group Java can see account A on Accounts list and can assign cards using this account.
### Accept/Reject card
**Use case 1:** Group limit of PO: 100$.
1. Operator A from the group HR assigns a card with a total limit 100$. Card is created with a status Accepted. Actions available for this card for operators from PO group are: Edit, Cancel. Card is visible only on the Cards history tab.
2. Cardholder received an email notification with a card to redeem.
**Use case 2:** Group limit for HR: 100$ Group limit for Business: 200$.
1. Operator A from the group HR assigns a card with a total limit 150$. Card is created with a status CREATED. Actions available for this card for operators from PO group are: Edit, Cancel. Card is visible only on the Cards history tab.
2. Operator B from the group Business sees A’s card on the Awaiting cards and Cards history tab. Option available for this card for B are: Accept, Reject.
3. Operator B decides:
a. Accept - card changes its status to ACCEPTED and the cardholder receives an e-mail with a card to redeem.
b. Reject - card changes its status to REJECTED. No actions are available for this card. Operator A receives an e-mail notification about rejection.
### Request changes as cardholder
**Use case 1:** Corporate admin from group A with group limit 100$ have assigned the card for the cardholder and requested change of limit is below 100$.
1. Cardholder chooses the “Request changes” button in the mobile app and fills the form.
2. All corporate admins from group A see a new request on the Awaiting cards tab on Cards list. He wants to change the limit from 50$ to 90$.
3. Until there is no decision we see 2 states of this card on Cards list - the active one is in DELIVERED status and requested one is in CREATED status.
4. Corporate admin decides:
a. Accept - card changes its status from CREATED to DELIVERED and card with previous limits changes its status to REAPPROVED. Only one card is seen on Cards history list.
b. Reject - card changes its status from CREATED to REJECTED and card with previous limits stays with status DELIVERED. Both cards can be seen on Cards history list.
**Use case 2:** Corporate admin from group HR with group limit 100$ have assigned the card for the cardholder and requested change of limit is above 100$. Limit of group above (Business) is 200$.
1. Cardholder chooses the “Request changes” button in the mobile app and fills the form.
2. All corporate admins from group HR see a new request on the Awaiting cards tab on Cards list. He wants to change the limit from 50$ to 150$.
3. Until there is no decision we see 2 states of this card on Cards list - the active one is in DELIVERED status and requested one is in CREATED status.
4. Corporate admin decides:
a. Accept - card stays with a status CREATED but disappears from the Awaiting cards tab for all users from the HR group. Request goes to the group above Business. Corporate admin from Business group decides:
i. Accept - card changes its status from CREATED to DELIVERED and card with previous limits changes its status to REAPPROVED. Only one card is seen on Cards history list.
ii. Reject - card changes its status from CREATED to REJECTED and card with previous limits stays with status DELIVERED. Both cards can be seen on Cards history list.
b. Reject - card changes its status from CREATED to REJECTED and card with previous limits stays with status DELIVERED. Both cards can be seen on Cards history list.
### Redeem card
**Use case 1:** Start date of a card is actual date.
1. Cardholder receives an email with code to redeem card in mobile application. If they do not have an account, they receive an invitation email first.
2. Cardholder fills 6 digits code for redeeming card.
3. In the next step the cardholder receives confirmation code on the phone number that Operator has put in the Assign card form. Cardholder fills this code in a mobile application.
4. Card is redeemed and ready to use. In the Corporate panel card changes its status to DELIVERED.
**Use case 2:** Start date of a card is in the future.
1. Cardholder receives an email with code to redeem card in mobile application. If they do not have an account, they receive an invitation email first.
2. Cardholder fills 6 digits code for redeeming card before the start date of a card.
3. In the next step the cardholder receives confirmation code on the phone number that Operator has put in the Assign card form. Cardholder fills this code in a mobile application.
4. Card is redeemed but the cardholder can’t use it yet. In the Corporate panel card changes its status to PREPARED.
5. When the actual date meets the start date of a card, the cardholder can use a card. Then it changes its status to DELIVERED.
In both cases cards can be used until the end date of a card or until Corporate Admin unassign a card from the cardholder. Then the card changes its status to FINISHED.
### Reassign card
Reassign card option can be used to assign a card for the same cardholder one more time.
1. Card changes its status to FINISHED.
2. Corporate admin chooses option “Reassign card” on card details or cards list.
3. Reassign card is displayed with already filled fields: Cardholder e-mail, cardholder phone number, account, total amount, periodic limit. All fields apart from cardholder e-mail and cardholder phone number can be changed.
4. After adjusting data, the Corporate Admin saves form.
5. Cardholder receives an email with code to redeem card in mobile application.