Page Comparison

The Tenant Management grid displays a visual representation of the active tenant for the user’s organization. Admin users can edit tenants by interacting with the Tenant Management Grid.

...

Aging: Services can be Aged, which allows them to be reused after a particular window of inactive time.

• Services: A non-negative (including zero) number of days to leave Inactive Services deactivated before putting them through Service Aging. Zero is respected here, allowing Services to be made available the next time the Aging Event runs. Aging will use the Service's Catalog Aging setting if it has one, otherwise, this value will be used.

Archiving: Some data is Archived by moving old records to cloned tables so current data can continue to perform well. This reduces the load on the database to work with millions of records at a time, most of which are no longer useful on a day-to-day basis.

• Calls: A non-negative (including zero) number of days before call data is Archived according to Date/Time the Call occurred. If left empty or 0 is set, 90 will be used instead.

• Call Errors: A non-negative (including zero) number of days before Call Error data is Archived. This window can be shorter than typical Call data because it can't be processed for billing. Because the date of the call may fail to import properly, Errors are archived according to the record's Created Date (effectively, Import Date). If left empty or 0 is set, 90 will be used instead.

• Bill: A non-negative (including zero) number of days to wait after a Bill is generated to archive its data. This window is based on the date the Bill was generated.

• Service Desk: A non-negative (including zero) number of days to wait before Archiving valid Service Desk records. The default value is 365 days. Zero is permitted to Archive Eligible records immediately, though NOT recommended.

Data Retention

Excerpt

PCR-360 is capable of generating large amounts of data. Proper data retention policies and clean up processes will help to keep PCR-360 running as optimal as possible. Retention values apply to the length of time data is preserved before being permanently deleted from the application, whereas Aging is how long Services (or other entities, potentially) retain their current data associations before being "cleaned" for reuse. As a last distinction, Retention and Aging are both separate from Archiving, which defines how long data remains in the "primary" tables. Data Retention values define how long, in days, the records are kept. Zero indicates records are cleaned up immediately. A negative number is not allowed, but if left blank the event will not clean up any records. Data Retention Events will only clean up the oldest months worth of data per run until the data retention days threshold. This ensures the system is not bogged down when there is a backlog of records. To utilize this event effectively it is recommended to run weekly. Once caught up, it can be changed to monthly, although any performance gains would likely be negligible. Please contact the helpdesk with questions, or for assistance setting up retention policies. API Request Logs       The API Request Logs Deleted event recurs daily to cleanup outstanding REST API Request Logs. The number of days the Log is Retained is set on the Manage API Keys form.      Authentication Log The Authentication Log cleanup event recurs weekly, is set to pending by default, and has a default retention value of 365 days. The retention value is set on the Manage Tenants form. Image Modified Bulk Update History The Bulk Update History cleanup event recurs weekly, is set to pending by default, and has a default retention value of 365 days. The retention value is set on the Manage Tenants form. Imports The Delete old Import Files and Imported Records event recurs every day to cleanup records. The retention value for the records is set on the Manage Import File Format form. If the retention value is set too soon it could limit PCR's ability to troubleshoot issues relating to that import format. Image Modified Messages The Messages cleanup event recurs weekly, is set to pending by default, and has a default retention value of 365 days. The retention value for this event is set on the Manage Tenant form. System Messages (BIll generation, Bulk updates, etc.) and Messages of Inactive Users are effected by this event. The PCR-360 messaging system allows Users to send and receive messages from other PCR-360 users, those messages are not deleted by this cleanup event.

...

To set up the initial association:

1. In the PCR-360 Application, navigate to Admin → Tenant Management.
   
   

2. Select the record in the grid.
   
   

3. Select the Emails Tab
   
   

4. Click the Add button.

PCR-360 is now ready to have a Email Address configured.

Registering An Application in the Portal

1. Open a browser and navigate to the Azure Active Directory admin center.
   
   

2. Login with an account capable of administrating Active Directory
   
   

3. Select Azure Active Directory in the left-hand navigation, then select App registrations under Manage.

   Image Modified

4. Select New registration. On the Register, an application page, set the values as follows.
   
   

   • Set Name to "PCR360 Production" (or "PCR360 Test" depending on the environment being set up).
     
     

   • Set Supported account types to Accounts in any organizational directory and personal Microsoft accounts.
     
     

   • Under Redirect URI, set the first drop-down to Web and set the value to
     
     

     • This must be altered to reflect the URL of the PCR-360 Application
       
       

     • Appending /core/oauth2/validated to the end of the URL is required
       
       

     • https://<pcr360.customerUrl.edu>/core/oauth2/validated
       
       

5. Select Register. Copy the value of the Application (client) ID and save it, you will need it later.
   
   

6. Select Certificates & secrets under Manage. Select the New client secret button. Enter a value in Description and select one of the options for Expires and select Add.
   
   

7. Copy the client secret value before you leave this page. You will need it later.

   Important

   This client secret is never shown again, so make sure you copy it now.

   Image Modified

8. Select API permissions in the side bar
   

   Image Modified

   
   
   

9. Add the permission as shown
   
   

10. Click Add a permission and select Microsoft Graph
    

...

1. Image Added

   
   
   

2. Select Delegated Permissions
   

   Image Modified

   
   
   

3. Select the Mail.Read and Mail.Send permissions
   

   Image Modified

4. Select the User.Read permission
   

   Image Modified

   
   
   

5. Click the Add permissions button to add the selected permissions
   

   Image Modified

Configuration:

Below is an example for configuring a Microsoft Email to be used by PCR-360

1. Select the appropriate Account Type. 
   
   

2. MAKE SURE TO USE THE EMAIL ADDRESS YOU WANT PCR-360 TO USE
   
   Image Modified
   
   

3. On the OAuth2 Configuration tab enter Application ID and Secret KEY copied down from the Registering an Application steps above.
   
   

4. Also enter in the following values:
   
   

   1. Authentication Authority URL: https://login.microsoftonline.com/common for this example
      
      

   2. Authorization Endpoint: /oauth2/v2.0/authorize
      
      

   3. Token Request Endpoint: /oauth2/v2.0/token
      
      

   4. Scopes (groups, or permissions): openid profile offline_access user.read mail.read mail.send

...

1. 1. Image Added

2. Save the Email Address
   
   

3. Click the "Click to Authenticate" button
   
   

4. Follow the prompts to authorize PCR-360 with your Email.
   
   

5. Once completed the portal will redirect back to the application with a success message.
   
   

6. The button on the OAuth2 Configuration tab should now say "Click to RE Authenticate"
   Image Modified
   
   

7. The application is now configured to send (and/or receive) emails using the email address that was authenticated