You can create custom fields (extra data fields) throughout your Atera platform. They can appear in Ticket, Customer, Contact, Contract, SLA, Agent, SNMP, TCP, HTTP, and Generic forms/pages. You can also create script-based custom fields. Once you add a custom field, it will always appear (unless edited or deleted). For example, if you add a 'ticket' custom field, it will appear on all ticket forms.
You can create custom fields (extra data fields) throughout your Atera platform. They can appear in Ticket, Site, User, SLA, Agent, SNMP, TCP, HTTP, and Generic forms/pages. You can also create script-based custom fields. Once you add a custom field, it will always appear (unless edited or deleted). For example, if you add a ticket custom field, it will appear on all ticket forms.
Custom field locations
Add custom fields to tickets, sites, users, agents, and devices.
Add custom fields to tickets, customers, contacts, contracts, SLAs, agents, and devices.
Note: For ticket-related custom fields, you can choose whether the field is visible and editable to users in the Service Portal.
Note: For ticket-related custom fields, you can choose whether the field is visible and editable to contacts in the Customer Portal.
Custom field types
- Text: Enter a textual input.
- Number: Enter a numerical value.
- Date: Use a calendar date picker (format: mm/dd/yyyy).
- Checkbox: Check a single-option checkbox.
-
Dropdown: Choose from a list of options.
- Note: Each input value is limited to 100 characters.
-
Dropdown with dependencies: Use a conditional dropdown list based on previous selections.
- Note: Each input value is limited to 100 characters.
-
Script-based (agent only)
- Text: Textual input driven by scripts.
- Number: Numerical input driven by scripts.
Note: Custom fields support HREF links, allowing you to link directly to external documents, dashboards, or other relevant online resources, making them even more versatile and useful in daily operations.
Add a custom field
To add a custom field:
1. Go to Admin > Data management > Custom fields.
The Custom fields page appears.
2. Select a tab to add a new custom field.
The Add Field screen appears.
4. Fill out the fields:
- Target: The target is already selected by default (based on the tab you selected).
- Type: Select the field type.
- Title: Enter the field title of the field.
-
Subtitle: Enter the subtitle of the field.
- This is available for dropdown with dependencies custom fields.
-
Required field: Set the field as 'Required' or 'Not Required'
- This is not available for agent custom fields.
-
Service Portal configurations: Decide if users can edit the field within the Service Portal or hide it from view.
- This is available for ticket custom fields only.
-
Customer Portal configurations: Decide if contacts can edit the field within the Customer Portal or hide it from view.
- This is available for ticket custom fields only.
-
Values: Click the plus icon to add a new value. Then enter the value.
- This is available for dropdown and dropdown with dependencies custom fields.
-
Child values: Click the plus icon to add a new child value. Then enter the value.
- This is available for dropdown with dependencies custom fields.
5. Click Add.
The new custom field is added and will appear on the form/page.
Create custom ticket statuses
While custom fields are editable, most default Atera fields are not. The exception is the ticket 'Status' field, where you can add extra values that will appear in all your Atera tickets. For more details, see Custom ticket status
Script-based custom fields
Atera's script-based custom fields enable dynamic data input, allowing you to monitor any value for enhanced functionality and flexibility.
Note:
- This feature is available for Atera Enterprise users with Admin permissions only.
- This feature is available for Atera Superpower users with Admin permissions only.
- Script-based custom fields are available to Windows agents in the new Agent console.
- Script-based custom fields support .ps1 files, but not scripts with variables.
- There is no character limit to script-based custom fields.
- Script-based custom fields are updated once every 12 hours, or when you access the agent page on a Windows device.
To add a script-based custom field:
1. Go to Admin > Data management > Custom fields.
The Custom fields page appears.
2. Select the Agent tab. Then click Add field.
The Add Field screen appears.
3. Fill out the Add field field form:
- Target: Select Agent.
- Type: Select Script based.
- Output type: Select Text or Number.
- Title: Enter a field title.
- Monitoring script: Select the script (you can create or generate scripts — or clone one from the Shared Script Library to your My scripts tab).
4. Click Add.
The script-based custom field appears.
The output from these scripts populates the custom fields you've set up, making the data available directly within your agents (under the Custom fields tab).
Commonly used script-based custom fields
Outlined below are commonly used script-based custom fields. To learn how to upload a script to Atera, please refer to this article:
Check TPM
This script checks whether the Trusted Platform Module (TPM) is present and enabled on a device. TPM is a hardware component used for securing hardware through integrated cryptographic keys.
Script Explanation:
- The script queries the TPM status using the Windows Management Instrumentation (WMI) service.
- If no TPM is found, the script will output "Disabled."
- If TPM is found and is enabled, the script will output "Enabled."
- If TPM is found but is not enabled, the script will also output "TPM found, not enabled."
When uploading the script, ensure that it is executed with "System" privileges. Additionally, when creating the script-based custom field, set the "Output type" to "Text."
# Check if the TPM is present
$tpm = Get-WmiObject -Namespace "Root\CIMv2\Security\MicrosoftTpm" -Class Win32_Tpm
# Determine the TPM status and output the result
if ($tpm -eq $null) {
Write-Output "Disabled"
} else {
if ($tpm.IsEnabled) {
Write-Output "Enabled"
} else {
Write-Output "TPM found, not enabled"
}
}
Chassis type
This script determines whether a device is a laptop or a desktop based on its chassis type. The chassis type is a hardware classification that identifies the physical form of the device.
Script Explanation:
- The script retrieves the chassis type using WMI.
- It checks if the chassis type matches any of the values that typically indicate a laptop (such as chassis types 9, 10, 14, 30, or 31).
- If a match is found, the script will output "Laptop."
- If no match is found, the script will output "Desktop."
When configuring the script in Atera, ensure it runs as "System" and that the "Output type" is set to "Text."
# Get the chassis type(s)
$chassisTypes = Get-WmiObject Win32_SystemEnclosure | Select-Object -ExpandProperty ChassisTypes
# Check if the chassis type indicates a laptop
$isLaptop = $false
foreach ($type in $chassisTypes) {
if ($type -in 9, 10, 14, 30, 31) {
$isLaptop = $true
break
}
}
# Output result
if ($isLaptop) {
Write-Output "Laptop"
} else {
Write-Output "Desktop"
}
OS Install date
This script retrieves the installation date of the Windows operating system on a device. Knowing the OS installation date can help in understanding the system's age and planning for upgrades or maintenance.
Script Explanation:
- The script queries the installation date from the operating system using WMI.
- It converts the installation date to a more readable format (DD/MM/YYYY).
- The formatted date is then output as a string.
Run the script using the "System" option, and when creating the script-based custom field, set the "Output type" to "Text."
# PowerShell script to get OS installation date in DD/MM/YYYY format
# Get the OS installation date from the registry
$osInstallDate = (Get-WmiObject -Class Win32_OperatingSystem).InstallDate
# Convert the date to DD/MM/YYYY format
$formattedDate = [Management.ManagementDateTimeConverter]::ToDateTime($osInstallDate)
# Display the date in DD/MM/YYYY format
$formattedDate.ToString('dd/MM/yyyy')
Current user
This script identifies the currently logged-in user and checks if they have administrative privileges. This information is crucial for security monitoring and ensuring that users have the appropriate access levels.
Script Explanation:
- The script retrieves the username of the current logged-in user.
- It checks whether the user has administrative privileges.
- The script then outputs the username followed by their role, either "Admin" or "User."
Ensure the script is run as the "Current User" in Atera, and when creating the script-based custom field, select the "Output type" as "Text."
# Get the current username
$currentUserName = [Environment]::UserName
# Check if the current user is an admin
$isAdmin = (New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
# If the user is an admin, set the role to 'Admin', otherwise set it to 'User'
if ($isAdmin) {
$role = 'Admin'
} else {
$role = 'User'
}
# Output the username and role
Write-Output "$currentUserName - $role"
Uptime
This script calculates and displays the amount of time a device has been up and running since its last boot. Tracking uptime can be useful for monitoring system stability and ensuring devices are rebooted regularly.
Script Explanation:
- The script calculates the time difference between the current date and time and the last boot time of the device using WMI.
- It then formats this uptime into a string showing the number of days, hours, and minutes the device has been operational.
- The formatted uptime is then output as a string, in the format "X Days Y Hours Z Minutes" where X, Y, and Z represent the respective durations.
When configuring this script, ensure it is executed with "System" privileges, and set the "Output type" to "Text" when creating the script-based custom field.
$uptime = (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
$formattedUptime = "{0} Days {1} Hours {2} Minutes" -f $uptime.Days, $uptime.Hours, $uptime.Minutes
$formattedUptime
Edit or delete custom fields
You can easily edit or delete the custom fields you create.
To edit a custom field:
1. Click the edit icon on the custom field.
The Edit field window appears.
2. Update the custom field. Then click Apply
To delete a custom field:
1. Click the delete icon on the custom field.
A confirmation window appears.
2. Click Delete.
The field and its data are removed from all associated pages/forms.