Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information.md

+# Description of functionality for the process of Processing access requests
+
+## Introduction
+
+This article describes the specific functionality established for the
+\"Access Request Processing\" process. In addition to system
+capabilities and capabilities in standard case management, the process
+has the following functionality:
+
+-   Integration with eInnsyn
+
+-   Workflow
+
+-   Reductant
+
+-   Public form
+
+## Integration with eInnsyn
+
+The integration with eInnsyn is handled by the spoke \"UH eFormidling
+Spoke\". Every 5 minutes, UH Sak v / ServiceNow retrieves new registered
+access requests and creates corresponding case complex for further case
+processing.
+
+To ensure that cases are routed correctly and that the correct
+processing unit is set, access requests are split at the registration
+level. A case file with two registrations and associated documents will
+then become two unique cases in UH Sak. For
+example:![](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/0c10029f715249d78fe07439a98c91e40becf7ca.png){width="5.0in"
+height="1.3125in"}
+
+We receive the following information with the access request from
+eInnsyn:
+
+-   Orderer\'s e-mail address
+
+-   eInnsyn\'s unique ID on current Access request
+
+-   Name of unit (E.g. NTNU)
+
+-   Case number folder
+
+-   Journal entry
+
+-   Document number
+
+## 
+
+## Workflow
+
+The Transparency Request Management workflow has the following order:
+
+1.  Creating a case
+
+2.  Case processing
+
+3.  Approval
+
+4.  Dissemination of decision
+
+Creating a case
+
+An application for a request for access may be made in the following
+channels:
+
+1.  Outlook add-in
+
+2.  Manually registered by case worker
+
+3.  Publicly available form
+
+4.  eInnsyn
+
+Case processing for the first three channels is identical, here the case
+worker must manually search for the documentation and there is no
+metadata that can contribute to case routing and access management.
+
+For access requests that come via eInnsyn , there are the following
+support functions:
+
+1.  **Lookup against the archive core.** If the system is able to find
+    the specified case folder and journal entry in the archive kernel,
+    the following will occur:
+
+    a.  The case worker will be assigned to the same case worker who
+        originally handled the case (If he exists as an active user)
+
+    b.  The case processing unit will be assigned the same department as
+        the original casesdeals with
+
+    c.  Documentation will be downloaded. Both public version and
+        archive version if present.
+
+Case processing
+
+Case processing consists of assessing the documentation requested for
+access and, if necessary, redactingon the documentation where it can be
+partially appropriated.
+
+If a new or updated public version of the documentation is created in
+the process, it will be uploaded on the original case if possible. This
+happens automatically if access is Granted or partially Granted.
+
+Approval
+
+Approval of the Freedom of Information request follows the same process
+as during basic case processing.
+
+Dissemination of decision
+
+When the decision is approved, all documentation that has been granted
+access to will be collected on the same registration. The documents sent
+out will now be able to be viewed together under the tab
+\'Documentation\' and the decision that has been prepared. The decision
+will be so-called \"Main Document\".
+
+When using the component for \"Dissemination\" for sending out
+decisions, all documentation will now be automatically included.
+
+See also the document \"Dissemination of decision\"
+
+## 
+
+## Reductant
+
+Reductant is a capability that is available for all processes, but for
+the process \"Request for access\", this functionality also has an
+interaction with the processing of the document to which access is
+requested. As described under \"Workflow\", the system can automatically
+identify if a new redacted version is being created and update the
+original journal entry.
+
+See also the document \"How to redact a document on UH Task\".
+
+## Public form
+
+UH Sak comes with the possibility of using a public form for
+applications for access.
+
+![Graphical user interface, text, application, email Description
+automatically
+generated](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/media/image2.png){width="6.3in"
+height="6.1930555555555555in"}
+
+Access requests that are registered via the public form become a
+registered case of the type \"Access request\".
+
+The system will attempt to folder the provided email address of an
+existing user, if there are no matches, the system will create a
+contact. Illustrated:
+
+![](uploads/Funksjonell-beskrivelse/16.3-EN-Description-of-functionality-for-the-process-of-requesting-information/786575259c2470822b9feae359d3edef201a4357.png){width="6.228813429571304in"
+height="3.0625in"}