This articles discusses the most common configuration issues found on Travel Registry sites and how to address them.
Note: Beneath some topics is an internal link for Terra Dotta Support Agents. This link provides our Support Agents with additional back-end steps they could take if the steps provided in this article do not resolve the issue. It is expected that these linked pages will not be accessible to external audiences.
Index
1. Why did a certain workflow get triggered? / Why does the trip have these requirements?
2. The trip does not have any requirements or approvals.
3. A traveler can't see their trip when they log in.
4. Travelers are required to enter profile information, but no workflow requires this.
5. Can requirements be removed from a trip?
7. A trip to Mexico has a DOS rating of 3, but travel.state.gov does not show a rating for Mexico.
8. How can I refresh a traveler's profile?
9. The traveler's profile is not updating.
10. The approver has not received a request to approve a trip.
11. All approvers are receiving approval requests at the same time.
12. The delegate cannot see their traveler's trips/is not being notified.
13. Travelers do not appear in Traveler Locations.
14. Traveler has the wrong role.
15. Traveler has no name; the name appears as a comma.
16. Traveler has multiple accounts.
17. The traveler cannot log in.
18. I accidentally deleted a trip. Can I restore it?
19. How can I delete a trip without notifying the traveler?
20. Can I register trips that have already ended?
Note: For FAQ/Troubleshooting steps regarding Traveler Locations, AlertTraveler, or the License Manager see: AlertTraveler® Troubleshooting/ FAQ: Top 20 Most Common Issues and Questions
Common Issues/Questions
1. Why did a certain workflow get triggered? Why does the trip have these requirements?
To determine why content, forms, requirements, or approvals (collectively referred to as elements) appear on a certain trip, compare the trip, and the profile of its associated traveler, with the workflows on your site.
Suggested steps:
1. On the admin Travel Registry site, open the trip in question, as well as the traveler's profile. Note the details of both. It can be helpful to keep each page open on a separate screen.
2. Navigate to Travel Admin>Workflows and search for the workflows that contain the content, forms, requirements, or approvals that you are enquiring about.
3. Compare the conditions of the workflows that deploy the content with the traveler's profile and their trip.
Example: I am wondering why this traveler is required to upload their passport, and why the trip below has the "High Risk Waiver Request" form:
If I navigate to Travel Admin>Workflows, and search for trips that deploy the "High Risk Waiver Request" form, I find the following workflow:
The conditions of this workflow are as follows:
- The trip must be to a location that is designated as a DOS level 3 or 4 AND
- The traveler must have the role of "Student" AND
- The trip must contain at least one leg that is not within the Unites States.
If I revisit the trip, I can see that this trip is to a location that has a DOS level of 3 (A), and the itinerary is to Cairo, Egypt (B):
If I click on the traveler's profile (the profile can be accessed by clicking on the traveler's name at the top of the trip), I can see that the traveler has a role of "Student":
This explains why the trip has the "High Risk Waiver Request" form.
If I search for workflows that require the traveler to upload their passports, I find the following:
As the traveler is a student, and their trip contains an itinerary outside of the United States, it is expected that their trip would trigger these workflows.
Tips for determining why elements are present on a trip:
1. Check all workflow types.
2. If you cannot see any active workflows that explain why an element was deployed to the trip, make sure to check the inactive workflows. It is possible that the trip triggered the workflow and the workflow was later made inactive. Elements deployed to a trip by a workflow will remain present on the trip after the workflow is made inactive.
3. Check your workflow history logs. It is possible the element was deployed to the trip by the workflow, but the element was later removed from the workflow. The history log will show this.
4. Check the Global History Log to see if any workflows have been deleted. It is possible the workflow that deployed these elements has since been deleted. Elements deployed to a trip by a workflow will remain present on the trip after the workflow has been deleted.
2.The trip does not have any requirements/forms/essential content/approvals.
If a trip does not have any requirements, forms, essential content, or approvals though it meets the conditions of at least one workflow that deploys these elements, check the trip's itinerary date. If the trip was created after the trip's itinerary ended, it is expected that no content, (requirements/forms/essential content/approvals) will apply to the trip.
3. The traveler can't see their trip when they log in.
If a traveler logs in but cannot see their trip, check the following:
1. On the admin Travel Registry site, check that the trip has not been deleted. Search for the trip in Travel Console>Search>Trip Search. If you are unable to locate the trip, search for it in Travel Admin>Admin Action>Deleted Trips. If the trip has been deleted, admins can restore the trip by selecting the checkbox next to the trip, and selecting Restore from the Options menu.
2. If you have verified the trip has not been deleted, next verify that the user does not have two accounts. To do this navigate to Travel Console> Search>Profile Search. Search for the user by name in the keyword search field, rather than the traveler search field: If the user has two accounts, this indicates that they are likely logging into the account that is not associated with the trip. Users with several accounts will typically have an internal account that is integrated with the institution's student information system/HR file, and a second/third/etc. account that they created manually. These additional accounts will be external and not integrated. Ideally, all trips should be associated with the internal account, as this account's profile is auto-populated information from the SIS/HR file. If the trip is associated with what appears to be an internal account, ask the traveler to log in to the Travel Registry site using the internal log in option, and their university credentials.
4. Travelers are required to enter profile information, but no workflow requires this.
If you have checked every workflow type, and do not see any workflow requiring the profile parameter, the situation typically occurs due to one of the following scenarios:
-
- The requirement was triggered by a workflow that is now inactive. It is possible that the traveler triggered the workflow and the workflow was later made inactive. Requirements deployed to a traveler's profile or trip by a workflow will remain present on the trip or profile after the workflow is made inactive.
- The requirement was triggered by a workflow that has since been edited. It is possible the element was deployed to the trip by the workflow, but later removed from the workflow. The workflow's history log will show this.
- The requirement was triggered by a workflow that has since been deleted. Check the Global History Log to see if any workflows have been deleted. It is possible the workflow that deployed these elements has since been deleted. Elements deployed to a trip by a workflow will remain present on the trip after the workflow has been deleted.
5. Can requirements be removed from a trip?
No, requirements cannot be removed from a trip. Once a workflow has been triggered, the deployed requirements will remain on that trip permanently. The admin can complete the requirement on the traveler's behalf, or the trip can be deleted, the workflow adjusted to exclude the conditions of their trip, and then the trip can be recreated.
Note: If the trip is deleted, the user will be sent an email notification that their trip has been deleted.
6. A workflow was triggered for a certain DOS/Risk rating, but the trip is not to a destination with that rating.
It is possible that the DOS rating has changed since the trip was created, or the trip was initially to a location that had the risk rating configured in the workflow, but the location of the trip was later changed. Remember, once a workflow has been applied to a trip, its content, requirements, and required approvals will remain on that trip permanently.
If the workflow has a regional DOS rating condition, it is important to remember the workflow logic for regional DOS Risk Ratings is as follows:
If a country has an area within it that has the risk rating selected in the workflow, the workflow will be triggered, regardless if the itinerary is to the specific location with that rating.
7. A trip to Mexico has a DOS rating of 3, but travel.state.gov does not show a rating for Mexico.
As of 5/28/24, it is expected that Mexico will display as a DOS level 3 in AlertTraveler and Travel Registry products. Though https://travel.state.gov does not explicitly show Mexico's DOS level in its user interface, XML information from that site indicates Mexico is a level 3. Though this can cause confusion, Terra Dotta software must default to the data provided. Workflows in Travel Registry should be edited to accommodate the institution's process regarding trips to Mexico.
8. How can I refresh a traveler's profile?
A traveler's profile can be refreshed by navigating to the user's profile and selecting "Refresh Profile" at the bottom of the page:
This will refresh the user's profile with the SIS/HR information that was most recently loaded to the Travel Registry site.
9. The traveler's profile is not updating.
If the Traveler's profile is not updating, it is possible that they do not meet the conditions necessary to be considered "Active" in terms of the SIS Refresh.
It is important to note that not all user's profile information will be refreshed nightly. For a user's profile information to be refreshed nightly, meaning the values of their parameters are updated to match the information in the SIS/HR file, they must be considered an 'active' user.
Active users are:
- Travelers that have a current or future trip
- Members of any permission group in Travel Admin>Staff Management
Note: Users are considered active if they meet one or both of the above conditions; they do not need to meet both conditions.
If data was present for the user at the time they became active but is not provided in later files, the previous data will remain in the user's profile. This is because the refresh process does not allow null data to replace existing data.
Profiles are refreshed:
- Nightly (for active users)
- Upon user creation
- When an active traveler navigates to their profile
- When a new trip is created (if the traveler's profile has not been refreshed in the last 24 hours)
If the traveler meets these conditions, check with your IT department to confirm the user is in the nightly SIS/HR data file.
10. The approver has not received a request to approve a trip.
Take the following steps to determine why an approver has not received an emailed request to approve a trip:
- Check the status of the trip. Trip's that have been submitted for approval will have a status of Awaiting Approval:
Trips with a status of Approval Needed have yet to be submitted for approval, so it is expected that the approval will not have received an emailed request to approve a trip.
Note: When checking the approval status, check the upper right corner of the trip. The Pending status, seen in the Approval History tab, only indicates that the trip has not yet been approved and will require approval; it does not indicate if the trip has been submitted for approval.
If the trip has a status of Awaiting Approval, check the Global History log to confirm the email was sent to the approver. If the email was sent, but the approver claims they did not receive it, it is likely the case that the email was flagged as spam. The admin will need to contact their institution's IT department to determine why emails sent from alerts@alerttraveler.com are being suppressed.
11. All approvers are receiving approval requests at the same time.
If your approvers are receiving their approval request emails at the same time, when you would prefer them to receive the requests sequentially, the issue is likely the configuration.
Check your approval workflow(s) to determine if the approval types are set to Simple:
If you have more than one Simple workflow and/or a single workflow with several Simple Approval types, they will all be kicked off as soon as the trip is submitted for approval.
To determine the order approval requests will be sent, it is necessary to create a sequential approval:
In the image above, the Department approver(s) will receive the approval request first. If they approve the trip, the College approver(s) will receive the approval request email.
12. The delegate cannot see their traveler's trips/is not being notified.
If the delegate cannot see their traveler's trips, and is not being notified of actions taken on the trip as expected take the following steps:
1. Verify that the delegate relationship is configured correctly.
To do this, navigate to Travel Admin>Delegate Center and search for the traveler. In the image below, we can see that Madelyn is the delegate for Abigail Adams:
If we click the delegate's name, we can see that Madelyn is configured as a Standard admin:
This means she can create, complete and submit trip registrations on behalf of the traveler. She will receive email notifications if the trip is approved or rejected.
If Madelyn were configured to be a Standard+Notify delegate she would have the capabilities of the standard admin, but they will also be notified via email when the trip starts and ends, if the traveler is impacted by an alert, and if the traveler submits a Help Request.
If the delegate relationship is set up correctly, but the delegate is still cannot see the trip and/or is not receiving notifications, proceed to step 2.
2. Verify that the delegate created the trip.
Delegates will only be able to see/be notified of trips that they create on the traveler's behalf. To confirm which user created the trip, navigate to Search>Trip Search. From the Hide/Show dropdown menu, select Created By:
Selecting Created By from this dropdown adds the Created by column to the Trip Search interface. This column will indicate if the traveler or the delegate created the trip:
In the image above we can see the traveler created this trip, so it is expected that the delegate cannot see the trip in their homepage and is not receiving notifications.
Note: You may need to check the trip's history log to determine which delegate created the trip.
If the delegate created the trip, but is still not being notified via email, verify if an email was sent in the Global History log. If the email was sent but the user did not receive it, the admin will need to contact their institution's IT department to determine why the email is being flagged upon delivery.
If all looks to be configured correctly, and you have verified the email was not sent, try removing the delegate from the user in Travel Admin>Delegate Center:
Then add the user again and ask the delegate if they see the traveler's trip in their Travel Registry home.
13. Travelers do not appear in Traveler Locations
If a traveler does not appear in Traveler Locations, check the following:
1. Navigate to AlertTraveler>Traveler Locations and check your filters carefully, particularly the Itinerary Date filter, which defaults to travelers who are abroad "today."
Make sure to select the Show Additional Features icon, to make sure no other filters are applied. The Abroad filter defaults to filtering for Itinerary Active:
If the traveler's itinerary indicates they are currently abroad skip to step 2.
2. Navigate to AlertTraveler>License Manager, search for the user associated with the trip and verify their activation/license status is either Subscribed or Activated. The license should not be expired.
3. If activation status is correct, search for the trip in question by navigating to Search>Trip Search and adjusting the filters. Once you have located the trip, open it and confirm the approval status in the top right corner of the trip modal:
If the trip requires approval, it will not appear in Traveler Locations until the trip has a status of Approved.
14. The traveler has the wrong role.
The role of the traveler is determined by several factors. To determine why a user was given a certain role, navigate to Travel Admin>Settings> Profile Mappings and review your settings.
The Role field in the Profile Mappings page allows the admin to configure the logic that determines the role of the user. Two default roles are available; one for internal users and one for external users. The internal default field determines the role of internal users who do not have a value in the SIS/HR file. The external user default field determines the value of all external users, until the value is changed by an admin or the traveler:
The values to the left are the options that will be in the data file for internal users:
In the example above, internal users with the value of Administrative in the value column of the SIS/HR data file will be given the role of Faculty/Staff. Internal users with the value of Student will be given the role of Student.
15. The traveler has no name; the name appears as a comma.
In Trip Search, you may see that one of your trips has no associated name, only a comma.
This typically happens when an user registers their trip but is not found in SIS/HR file. With Travel Registry, everyone who can authenticate via SSO can log in. Because the traveler was not included in the data file prior to authentication, the trip was created without their information.
To prevent this from happening in the future your office will need to ensure all potential travelers are in the data file and/or release first, last, and email to Terra Dotta upon authentication. A Support ticket will need to be opened with Terra Dotta to complete this process.
To fix this, the SIS/HR file needs to be updated to include the traveler. Once it is, wait for the nightly data loader job to run. Then refresh the traveler's profile.
16. The traveler has multiple accounts.
Users with several accounts will typically have an internal account that is integrated with the institution's student information system/HR file, and a second/third/etc. account that they created manually. These additional accounts will be external and not integrated. It is also possible that the admin inadvertently created the external account when they added the user to a group trip. Ideally, all trips should be associated with the internal account, as this account's profile is auto-populated information from the SIS/HR file. To resolve these duplicate accounts, open a case with Terra Dotta Support asking for assistance.
17. The traveler cannot log in.
If the site in question is using Single Sign On, and the traveler is an internal user that should have an institutional ID and password, remind the user to use this ID and password when logging in. Make sure they are logging in to the internal login, not the external login.
If the user is an external user and they have forgotten their password, they should select Forgot your password? from the login modal:
A password reset email should be sent to the user shortly.
If the user is assured of their credentials but cannot log in, check the AlertTraveler®: License Manager to ensure the site has not exceeded the license limit for the current year. If this site has exceeded the license limit, a case will need to be opened with Terra Dotta Support.
18. I accidentally deleted a trip. Can I restore it?
Deleted trips can be restored by admins by navigating to Travel Admin>Admin Action>Deleted Trips. Admins can restore deleted trips by selecting the checkbox next to the trip, and selecting Restore from the Options menu:
Note: Canceled trips cannot be reinstated. The trip will need to be recreated.
19. How can I delete a trip without notifying the traveler?
Deleting a traveler's trip will send them a notification email. To avoid this, open a case with Terra Dotta Support. Terra Dotta's Support agents have the ability to permanently delete trips. Selecting Permanent Delete from the Options menu will not notify the traveler.
20. Can I register trips that have already ended?
Yes, trips can be registered retroactively. However, workflows do not apply to trips that have an itinerary end date in the past.