Skip to main content
Skip table of contents

Tenant Management


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.

Example of the Tenant Management grid

Tenants

Example of the Manage Tenants form

In the Tenant Management data entry form, Admin Users are prompted to define some basic information.

Here, Users can define a Default NPA (a three-digit area code), Default NXX (the first three-digit prefix of a local phone number), and Default State. These values will pre-populate any fields of their respective types in the application.

Users must also apply a VIP Urgency designation to the tenant. If the user defines the VIP Urgency as "High", for example, all SD items owned by VIP users will indicate the elevated need for attention within the Service Desk.

Fiscal Wall

The 'Fiscal Start' field takes a two-digit month/day (MM/DD) to set the start time for an organization's Fiscal Year. This field sets a "Fiscal Wall" that will prevent Charges from being created for any date older than the set Fiscal Year when using Back Billing.

The 'Fiscal Start Next Year' will set the year to the following year if it is set to True. If the checkbox is not set then the current year is used instead.


Aging And Archiving

Several values control how old data is managed within the database.

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

Defines how long, in days, the records will be kept. Zero indicates records will be cleanup 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.

Message Retention: Defines how long, in days, System Messages and Messaged of Inactive Users will be maintained within PCR-360.

Bulk Update History: Defines how long, in days, Bulk Update History will be maintained within PCR-360.

Adding Email Accounts

An example of the Manage Tenants form with email Accounts tab focused

Users can also add email accounts to the tenant. These accounts serve as the "From" and "To" addresses for the automated email capabilities built into the application. Click on the 'Email Accounts' tab and click the 'Add' button (see image above).

An Example of the Add New Tenants Email Accountsform

In the form (see image above), Admin users are prompted to define a number of required fields for the new email account. This email account specification defines how PCR-360 will send and receive emails. PCR-360 sends email notifications and alerts, and can also "read" incoming emails to a specified email account. For example, if the subject of an incoming email references a specific Service Desk number, the application will add the email to the SD item's Email Thread; if no SD number is specified, the application will create a new Service Desk Inquiry.

Users must define all aspects of the new account, including 'Account Name', 'Account Type', 'Login' and 'Password', the 'Email Address' itself, and the 'Servers' that the account uses.

For more information about configuring Tenant Email, see:
https://confluence.pcr.com/pcr360/latest/resources/installation-guide/configuring-email



JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close