Create how the instantiation flow for apps should be in mvp

[helenekri]

Description

Use the information found in #1804 and specify how the instantiation flow should be for apps created in Altinn studio. Which parts of the instantiation flow should be a part of the app and which part(s) of the instantiation flow should be part of the platform.

Considerations

Currently we know that the following scenarios needs to be considered in the instantiation flow:

• You have an existing instance of this service in your message box
• Security level
• actor type requirement
• hooks
• roles
• no checks
• Deadline
• Expired / removed apps
  

Acceptance criteria

• We know the flow we wish to have for instantiations in mvp
• We have considered the different scenarios for what the instantiation can contain

Functionality that has been decided as out of scope for MVP

• Look into how to handle setting start - end date on an application. It will be looked into in a separate epic post-mvp how to handle this in the instantiation flow. ISSUE Document how to add start/end date to an app #1947
• We will not be integrating with the HELT solution regarding "Request a role" in mvp, this will be solved in an epic post-mvp. ISSUE Include HELT solution "request role" on instantiation of apps app-template-dotnet#30
• If you only have one actor you can represent, instead of asking the user to select the actor the system can ask if the user wants to represent the actor that meets the requirements. This is a type of step that we can test / look into post-mvp. ISSUE If user only have one party to represent, system should change party for end user app-frontend-react#149
• Handle no checks

How we have solved the instantiation flow for MVP

See the functional instantiation flow in Figma:
https://www.figma.com/file/UV91p8jihbapxusA85C9HuDu/Sluttbrukertjenester?node-id=1049%3A2039
Documentation on the functional instantiation flow in confluence:
https://confluence.brreg.no/display/T3KP/Instansieringsflyt+for+mvp
Technical documentation on how we solve the instantiation flow: https://docs.altinn.studio/architecture/application/altinn-apps/applicationevents/

Tasks

• Look at todays workflow currently described in Map out todays instantiation flow #1804
• Look into if there is any previous design work done on instantiation as part of the redesign project
• Set up and agree on a workflow that is possible from a technical and functional standpoint
• Create the functional workflow and document it
• Create the technical workflow and document it

[TheTechArch]

Insight in the use of level 4 services in Altinn 2 Platform
This is the services today.,

[TheTechArch]

Stats about use of do not prompt reportee

274.057 has selected this option

305.993 has defined a PreselectedReportee

144.134 has choosen both.

This from 4.959.252 user in Altinn today

[TheTechArch]

The following statistics show how users logs in to ID Porten
MinID OTC 527742 16.42%
MinID PIN 54261 1.69%
BuyPass 159282 4.96%
Commfides 1103 0.03%
BankID 1174407 36.55%
BankID mobil 1296615 40.35%

So 80% uses Level 4 authentication.
When you look at the low number of level 4 services the conclusion from my side is that the upgrade problem is not a very relevant problem for many. Most people will never experience it.

[TheTechArch]

Since 01.01.2019 it has been created 31.729.882 Reportee elements in Service Engine

8408 (0.03% ) Requires Level 4 authentication
6932996 (21.85%) Requires Level 3
14246867 (44.90%) Requires Level 2
11266687 (35.51%) Requires level 1
85553 (0.27%) Requirles Level 0

Based on this and the method statistics above, the upgrade scenario is somthing that happens very very seldom. (Since minimum level on ID porten is 3)