Overview
The University of Alaska (UA) Enterprise Service Management (ESM) system is a Software as a Service (SaaS) platform called TeamDynamix which has the following environments:
- Production - The production environment is the primary environment that the UA community will interact with, submit tickets, check status, etc.
- Sandbox - The sandbox environment is a copy of the production environment, running the same version as production. The production environment is typically copied to sandbox three (3) times a year.
- Release Preview - The release preview environment is a copy of production that is only available to ESM Enterprise Administrators in advance of a major release. The release preview environment runs the upcoming version. This environment is unavailable starting shortly after the major release until the next release preview period.
Enterprise Service Management Production
This is the primary ESM environment containing production configuration and data that the UA community will interact with, submit tickets, check status, etc. It can be accessed at https://service.alaska.edu.
Enterprise Service Management Sandbox
The ESM Sandbox is a copy of the production environment, running the same software version as production. Since it is a copy of production, it includes both configurations and transactional history (for example, both project type definitions and projects will be copied from production) as of the most recent data copy date.
The Sandbox environment is an excellent place for the following:
- Training new department employees
- Mocking up new, or refinements to, forms
- Building and testing workflows
The ESM Sandbox environment is never automatically refreshed. The ESM Enterprise Administrators will submit a request to the SaaS vendor scheduling the next refresh period.
Important
ESM App Admins will always be provided a minimum of two (2) weeks notice of when the next Sandbox refresh is scheduled via the Microsoft Team ESM App Admin.
When the sandbox environment is refreshed, a copy of the production database will be restored to the sandbox environment, replacing the existing database. This means that any configurations, testing, or experimenting that has been done in the sandbox will be lost when it is refreshed.
Warning
Its worth repeating. All configurations, testing, and/or experimenting that has been done in sandbox will be lost when it is refreshed! App Admins will need to either reproduce the changes in production before the refresh, or make notes so the settings can be reproduced after the refresh is complete.
The sandbox environment will be unavailable during these scheduled refreshes, which typically take between 30 - 60 minutes. Additionally, the sandbox will be unavailable during the vendor's quarterly multi-tenant sandbox refresh done on the first Monday day of business of the quarter. Only weekends and U.S. holidays are considered non-business days. The multi-tenant refresh will start approximately 4:00 am AK and typically take ~3 - 4 hours and is guaranteed to be completed by the end of the day at the latest.
Data for the refresh will be as of 7:30 pm AK the day prior to the refresh. For instance, if the refresh is on March 3rd, the data in the refresh will be as of 7:30 pm March 2nd.
Sandbox and Release Preview Environment Features
A number of features in the Sandbox and Release Preview environments are disabled or deactivated when the environment is copied from production in order to reduce the risk that an automated action in this environment conflicts with the production environment or confuses customers. The following features are disabled (cannot be used) or deactivated (turned off, but can manually be enabled).
Sandbox and Release Preview Features
| Feature |
Status |
Details |
| Email Monitors and Email Reply Monitors |
Disabled |
Non-production environments cannot read inbound email in order to avoid conflict with production. |
| Attachments |
Not Copied |
Attachments are not copied from the production environment. |
| Service Level Agreements (SLAs) |
Deactivated |
In-flight SLAs on tickets are removed and SLA definitions are deactivated. If you reactivate an SLA it will apply as normal to tickets created in the sandbox. |
| Scheduled Tickets |
Deactivated |
Ticket schedules are deactivated. If you reactivate a ticket schedule, it will create the ticket when its scheduled date is reached (if it is before the sandbox is next refreshed). |
| Project Update Schedule |
Deactivated |
The settings in the TDAdmin > Project Update Schedule page are modified as follows:
- Email reminders: Never
- Automatic Escalation Green to Yellow: Unchecked
- Automatic Escalation Green/Yellow to Red: Unchecked
|
| Project Hours Exceeded Notifications |
Deactivated |
The settings to notify a project manager when project hours exceed the scheduled or estimated hours are unchecked on individual projects and on project types. |
| User-defined Alerts |
Deactivated |
All existing user-defined item-level alerts are removed. New alerts can be created. |
| Time Report Alerts |
Deactivated |
The Time Report Alerts defined in TDAdmin are deactivated. |
| Ticket Surveys |
Deactivated |
Ticket surveys are deactivated. Note that project close surveys are not deactivated. |
| Report Delivery |
Deactivated |
All scheduled report deliveries are removed. |
| Ticket Goes Off Hold Date |
Deactivated |
All on hold tickets have their Goes Off Hold date removed. Existing tickets will not automatically go off hold. |
| Asset Discovery |
Deactivated |
All asset discovery scanners and discovery jobs are deactivated. |
| Web Hooks |
Deactivated |
Ticket, Asset and CI webhooks are deactivated. |
| Workflow Web Services |
Deactivated |
The configurations that enable ticket workflow web service steps are deactivated so that the sandbox environment does not accidentally update other production systems. This includes Workflow Web Service Auth Accounts, Methods, and Providers. If you are going to use the web service step to interact with ESM from the sandbox environment, you should verify that the URLs for auth accounts, methods and providers all use SBTDWebApi instead of TDWebApi. |
| Workflow Web Service Logs |
Not Copied |
All historical ticketing application workflow web service logs, as seen in TDAdmin > [Ticketing application] > Workflow Web Services > Workflow Web Service Logs, will be cleared as a part of the refresh. |
Need additional help or have issues
For support, requests may be submitted anytime using the appropriate Enterprise Service Management form. Requests generate a Ticket which will be worked in order received and urgency by IT Employees with the knowledge and permissions to assist with the request.
For immediate assistance please review the Contact Us page for the appropriate support group.