Fetching and Using the Current Date in ServiceNow: Business Rules, UI Actions, and Flow Designer

Setting the current date in a ServiceNow Business Rule is a common requirement for automating record updates and ensuring data consistency. Business Rules allow you to run server-side scripts when records are inserted, updated, or queried, making them ideal for tasks like timestamping events or populating date fields automatically. Fetching the current date/time is relevant in many scenarios on the ServiceNow platform, such as updating a "Last Updated" field, stamping a "Closed Date" when an incident is resolved, or calculating deadlines relative to today. By using Business Rules to fill in the current date, developers can eliminate manual data entry, maintain accurate timestamps, and trigger time-sensitive logic reliably.

Common scenarios where fetching the current date is necessary include:

• Audit and Logging Fields: Automatically setting fields like created on, updated on, or resolved date to the current date/time for record tracking.

• Workflow Triggers: Using the current date in logic to decide if certain processes should run (for example, starting a review if today is past a due date).

• Date Calculations: Initializing a date field (e.g., next review date) to the current date (or current date plus some offset) when a record is created or a status changes.

In all these cases, retrieving the current date/time within a Business Rule ensures the value is set on the server side, maintaining consistency regardless of user time zones or client-side manipulations. Next, we'll explore how ServiceNow Business Rules operate and then dive into various methods to fetch the current date using ServiceNow's API.

Understanding ServiceNow Business Rules and Execution Order

ServiceNow Business Rules are server-side scripts that execute based on record actions in the database. They are configured with a when to run setting that determines execution order relative to the database operation. The main types of Business Rules are: Before, After, Async, and Display.

• Before Business Rules: These run before the record is inserted or updated in the database. Use "Before" rules to modify field values or enforce validations prior to saving data. For example, setting a date field to the current date in a Before Insert rule will apply that value just before the record is written to the database. (ServiceNow automatically saves any changes made to the current record in a before rule, so no explicit update() call is required in the script. )

• After Business Rules: These run after the record has been inserted or updated in the database. "After" rules are ideal for post-processing actions that don't need to alter the record before save. For instance, you might use an After rule to create related records, send notifications, or log an event using the current date. If you attempt to change the current record in an After rule (for example, setting a date field), those changes will not be automatically saved because the record has already been written. In such cases, a current.update() would be needed to persist changes — however, this approach requires caution (explained in Best Practices below).

• Async Business Rules: Asynchronous rules are similar to After rules in that they run after the database commit, but they execute in the background (non-blocking). The user doesn't wait for an Async rule to complete. Async Business Rules are useful for operations that can happen slightly later or outside the main transaction, such as lengthy calculations or calling external APIs. You can fetch the current date in an Async rule just like in an After rule. The difference is timing: the script will run shortly after the record save, and any updates made will occur in a separate transaction. Async rules help improve performance for the end user, but remember that they don't run immediately at the moment of save (they execute a moment later, asynchronously).

• Display Business Rules: These execute when a record is queried from the database (for example, when a form is loaded). Display rules run before the data is sent to the client (browser). They are often used to prepare data for client scripts (using g_scratchpad). Display rules are generally not used for setting persistent record data because they don’t run during insert/update, but rather on read/display. Fetching the current date in a Display rule might be used for showing information on a form, but it would not save that date to the database.

  
  

Understanding the execution order is important because it guides where and how you should fetch the current date. For setting a field value like a timestamp, a Before rule on insert or update is usually the best choice (so the value is saved with the record immediately). If you used an After rule for this, you'd have to explicitly save the change, which could trigger another round of Business Rules (a potential pitfall). In summary, choose Before Business Rules when you want to modify the record being saved (e.g., setting a date field to now), and use After/Async for actions that use the date for other purposes (logging, notifications, calculations) without altering the just-saved record (or if altering, do so carefully).

Fetching the Current Date in Business Rules: Different Approaches

ServiceNow provides several ways to retrieve the current date and time in Business Rule scripts. The platform has a built-in GlideSystem object (gs) with convenience methods, as well as dedicated date/time API classes like GlideDate and GlideDateTime. Depending on your needs (date vs date-time, time zone considerations, etc.), you can use one of the following approaches:

1. Using gs.nowDateTime() (GlideSystem method)

The simplest way to get the current date and time in a Business Rule is by using the global GlideSystem object. In any server-side script (Business Rule, Script Include, etc.), gs is available for utility functions. The method gs.nowDateTime() returns the current date and time as a string.

• What it returns: gs.nowDateTime() produces a date/time string representing "now." The string is in the format YYYY-MM-DD HH:MM:SS (the user's current time zone by default). For example, it might return "2025-03-18 11:01:36" as the current date and time. This is essentially the platform's current timestamp in a human-readable form.

• When to use it: Use gs.nowDateTime() when you need a quick and straightforward way to get the current timestamp as a string, perhaps to set a Date/Time field or to include in a message. It's handy in global scripts and is easy to use for comparisons or assignments. Keep in mind that this returns a string, not a GlideDateTime object, so if you need to perform date calculations or comparisons, you might convert it to a GlideDateTime (e.g., new GlideDateTime(gs.nowDateTime())) or use the next approaches directly.

• Example usage in a Business Rule: Suppose you have a Date/Time field "start_time" on a task table that should be set to the current date/time when the record is inserted. You can create a Before Insert Business

  Rule and use gs.nowDateTime() in the script to populate this field:

// Before Insert Business Rule script
(function executeRule(current, previous /*null when insert*/) {
    // Set the start_time field to the current date/time
    current.start_time = gs.nowDateTime();  
    // No need to call current.update() in a before rule; 
    // the platform will save the change.
})(current, previous);

In this example, when a new task record is inserted, the start_time will be filled with a string like "2025-03-18 11:01:36" (representing the current date and time at execution). ServiceNow will automatically convert and store this value in the Date/Time field.

Note: gs.nowDateTime() is a global method. In newer ServiceNow releases and scoped applications, you might not be able to use some gs methods directly. If you are writing a script in a scoped application and gs.nowDateTime() is not available (or if it returns an unexpected value due to scope restrictions), use the GlideDateTime class as shown below. Additionally, remember that the string returned by gs.nowDateTime() is in the user's time zone. If your logic needs the system (UTC) time or you plan to compare this string with other date/time objects, be cautious. You may want to convert it to a GlideDateTime for accurate comparisons, since comparing a date/time string to a GlideDateTime object directly can be problematic. In general, for robust date handling, using the GlideDateTime API is recommended.

2. Using GlideDate() for Current Date (no time component)

If your use case only involves the date (and not the time of day), ServiceNow offers the GlideDate class. GlideDate manages dates without any time portion. This is useful for setting or comparing fields that are Date-only (not Date/Time fields) or when you only care about the date regardless of the time.

• Getting the current date: To fetch today's date using GlideDate, simply initialize a new object with no parameters. For example:

var gd = new GlideDate(); 

When you call new GlideDate(), it creates a GlideDate object initialized to the current date (based on the system clock). No additional arguments are needed; the object now represents "today's date."

• Assigning to a field: You can assign a GlideDate object directly to a Date field on the current record. ServiceNow will handle converting it to the proper format for storage. For example, in a Business Rule script:

var gd = new GlideDate(); 
current.due_date = gd; 
// assume 'due_date' is a Date type field (no time) 

This will set the due_date field to today’s date. If you prefer to be explicit, you could use gd.getValue() which returns the date in the system format "YYYY-MM-DD". Both assigning the object or the value string will yield the same stored result.

• When to use GlideDate: Use this approach for date-only fields or whenever you need just the date portion. Common examples include setting a Review Date to today when a record is updated, or defaulting a Contract Expiration Date to the current date if a certain condition is met. By using GlideDate, you ensure that you are not inadvertently including the time (which would default to midnight if you used a DateTime in a Date field). It keeps the logic clean for date comparisons as well.

• Example usage in a Business Rule: Imagine an application has a "review_date" field (Date type) on a Knowledge article, and you want to set it to the current date whenever the article is flagged for review. A Before Update Business Rule could do:

// Before Update Business Rule on Knowledge table 
if (current.needs_review == true && previous.needs_review != true) { 
	// The record is newly flagged for review 
	var today = new GlideDate(); 
	current.review_date = today;
}

In this snippet, when the condition to flag for review is met, the rule captures today's date in the today variable and assigns it to the review_date field. This ensures review_date is set to the exact current date (with no time component) at the moment the flag is turned on. The change will be saved with the record (because it's a before rule on update).

GlideDate has useful methods like getDisplayValue() (to get the date in the user's preferred format) and getDayOfWeek() etc., but for simply fetching the current date and saving it, just creating a new GlideDate is often all you need.

3. Using GlideDateTime() for Current Date and Time

For most cases that involve date and time together, GlideDateTime is the go-to API in ServiceNow. The GlideDateTime class handles both date and time, including time zone conversions and date arithmetic, making it very powerful for precise time stamps and calculations.

• Getting the current date/time: Similar to GlideDate, if you instantiate a GlideDateTime with no arguments, it initializes to the current date and time.

  For example:

var gdt = new GlideDateTime(); 

This gdt object now represents "now" (the exact date and time when that line executes). Under the hood, ServiceNow captures the current date/time in the system time zone (UTC by default) for this object.

• Assigning to a field: You can assign a GlideDateTime object to a Date/Time field on the current record. ServiceNow will convert and store it appropriately (as UTC in the database, typically).

  For example:

var gdt = new GlideDateTime();
current.start_time = gdt; 
// 'start_time' is a Date/Time field 

This will set the start_time field to the present moment. As with GlideDate, you could also use gdt.getValue() to get the UTC date/time string (e.g., "2025-03-18 02:01:36", which might be UTC) or gdt.getDisplayValue() to get the date/time in the user's time zone/display format. If directly assigning the object, ServiceNow effectively uses the internal value for storage.

• When to use GlideDateTime: Use GlideDateTime for any situation requiring the current date and time, especially if you plan to manipulate the time or need to ensure accuracy across time zones. It's the preferred method in scoped applications (since gs.nowDateTime() may not be available in scopes). Also, if you need to do things like add days or minutes, or compare two date-times, GlideDateTime provides methods (e.g., addDays(), getTime(), before()/after() comparisons, etc.). For simply fetching current time, it's straightforward, and for more complex operations, it’s indispensable.

• Example usage in a Business Rule: Consider a scenario with an "incident" table where when an incident is closed, you want to set a custom field "resolution_time" to the current date and time. You could use a Before Update Business Rule (condition: state changes to "Closed") to capture the moment of closure:

// Before Update Business Rule on Incident table 
// (when state changes to Closed) 
if (current.state == 'Closed' && previous.state != 'Closed') { 
	var nowDateTime = new GlideDateTime(); 
	current.resolution_time = nowDateTime;
}

Here, when the incident is being closed, new GlideDateTime() fetches the current timestamp and assigns it to resolution_time. Because this is a before-update rule, that value will be saved as part of the incident record as it gets closed. If the resolution_time field is a Date/Time type, it will store the full date and time of closure.

Tip: When using GlideDateTime, if you ever need the value in a specific format or time zone, you can use methods like gdt.getDisplayValueInternal() (for system format UTC), gdt.getDisplayValue() (in user format/timezone), or gdt.getValue() (which typically returns a string in UTC). But if your goal is simply to set a field or log the current time, the above usage is sufficient.

Step-by-Step: Setting Current Date in a Business Rule

To summarize the approaches above, here is a quick step-by-step guide for fetching and setting the current date/time in a Business Rule:

1. Determine the Business Rule timing: Decide whether to use a Before rule (recommended for directly setting a field on the current record) or an After/Async rule (if you need to perform actions after save or on a separate thread). For simply populating a field on the same record, a Before Insert or Update rule is ideal.

2. Choose the method to get current date/time: Depending on the field type and requirements:

   • Use gs.nowDateTime() for a quick string of current date-time (suitable for Date/Time fields or logging messages).

   • Use new GlideDate() for a date-only value (suitable for Date fields or when time is not needed).

   • Use new GlideDateTime() for a full date and time object (suitable for Date/Time fields and when further date operations are needed).

3. Fetch and assign the date in the script: In the Business Rule's script section, call the chosen method. Assign the result to the target field on current or use it in your logic.

   For example,

// Assigning a string value
current.my_date_field = gs.nowDateTime(); 

or

// Assigning a GlideDateTime object
current.my_date_field = new GlideDateTime();

This line will capture "now" at execution and prepare it to be saved on the record.

4. Avoid unnecessary updates: If you used a Before rule, do not call current.update() in the script. ServiceNow will save the current record automatically after the before script runs (including any changes you made to it). If you used an After rule and changed current, be aware that those changes are not saved unless you explicitly call current.update(). Generally, try to avoid updating the current record in After rules (see Best Practices below for why).

5. Test your Business Rule: After configuring, test the rule by performing the action (inserting or updating a record) that triggers it. Verify that the field is populated with the current date/time correctly. Check the format and time zone as needed. If using an Async rule, remember it runs in the background—ensure it eventually sets the field or logs the time as expected.

   
   

By following these steps, you can reliably fetch the current date/time in a Business Rule and use it to meet your requirements.

Best Practices and Potential Pitfalls

Working with dates in Business Rules is straightforward, but there are some best practices to follow and pitfalls to avoid to ensure your implementation is robust and doesn’t inadvertently cause issues:

• Use "Before" rules for setting fields: If your goal is to stamp a field on the record with the current date/time (such as setting a "Opened on" or "Last updated on" field), use a Before Insert or Before Update Business Rule. This way, the change is applied just in time for the database save, and you don't need extra code to persist it. It also means the field is set before any After rules or notifications fire, so other processes will see the correct updated value.

• Avoid using current.update() inside Business Rules: Calling current.update() within a Business Rule can lead to unintended consequences. In a Before rule, calling current.update() is not only unnecessary (the record is about to be saved anyway) but can cause an extra update operation and potentially trigger the Business Rule again, leading to an infinite loop or duplicate work. In an After rule, if you call current.update() to save a change (like setting a date), you will initiate a second update cycle on that record. This means the After Business Rule (and any other relevant rules) could run again on the update that you just triggered. Without careful conditions, this can cause a loop or at least multiple rapid updates to the same record.

  Best practice: If you must update a record in an After context, consider using an Async Business Rule or event to handle it separately, or ensure there’s a condition that prevents re-running the same logic on the second pass (for example, use a field or flag to check if the update has already been done). Often, rethinking the logic to use a Before rule or a Flow (as discussed below) can eliminate the need for current.update() entirely.

• Beware of time zone differences: ServiceNow stores Date/Time values in UTC in the database, but displays them in the user's time zone. When you use gs.nowDateTime(), it gives you the value in the current user's time zone by default as a display string. If you assign that to a field, ServiceNow will convert it to UTC for storage. Usually this is seamless, but if your script logic compares or manipulates dates, be mindful of whether you are dealing with user display strings or GlideDateTime objects (which by default handle UTC internally). A common pitfall is comparing a date/time string to a GlideDateTime; it’s better to convert strings to GlideDateTime or compare two GlideDateTime objects for accurate results.

  To avoid confusion, you can stick to GlideDateTime methods for any complex logic and only use display strings for things like user-facing messages or simple set-and-forget assignments.

• Use conditions to limit Business Rule execution: This is a general best practice. Ensure your Business Rule has a condition that it only runs when needed. For example, if setting a "Resolved Date" on incident closure, the rule should only run when state changes to Closed. This prevents the script from running unnecessarily on every update. It also can prevent that issue where an After rule update retriggers itself—by checking a condition or a flag, you can make the rule do nothing on the second update. In our incident example, once the "Resolved Date" is set, you might skip setting it again if it already has a value.

• Test in a non-production environment: Whenever working with Business Rules that update records (especially those using current date/time), test thoroughly in a dev or test instance. Verify that the date is correct, and watch out for any performance issues or loops. A Business Rule that unintentionally updates records repeatedly can cause performance problems or data inconsistencies. Logging with gs.info() during testing can help confirm the rule runs only when expected and the date values look right.

• Leverage platform features for dates: Sometimes, you might not need to script at all. For example, ServiceNow has dictionary settings like Default Value where you can use javascript:gs.nowDateTime() or similar to default a field to the current date/time upon record creation. This can handle simple use cases without writing a Business Rule script. However, for conditional or complex scenarios, Business Rules or Flows are the way to go.

  
  

By adhering to these best practices, you ensure that your Business Rules run efficiently and correctly. The key is to let ServiceNow do what it does best (auto-saving changes in before rules, handling time zones in its APIs) and to avoid forcing the system into repetitive or conflicting actions (like multiple updates or cross-triggering rules).

Alternative Solutions for Setting Date Values (UI Actions and Flow Designer)

While Business Rules are powerful for automating server-side logic like setting the current date, there are other options in ServiceNow to achieve similar outcomes. Depending on the requirement, you might consider using a UI Action or a Flow Designer flow instead of (or in addition to) a Business Rule. These alternatives can sometimes be more appropriate or easier to manage, especially for user-initiated actions or simpler use cases.

Using a UI Action to Set a Date

A UI Action is typically a button or menu item that a user can click in the UI (for example, a form button). UI Actions can execute server-side scripts (or client-side scripts) when clicked. If your use case involves a user explicitly triggering the setting of a date, a UI Action may be a good choice.

• When to use: Use a UI Action when the date should be set as a result of a user decision or immediate action, rather than automatically on every save. For example, a "Stamp Start Time" button on a task form could allow a user to set the start_time to now when work actually begins (rather than at record insertion). This gives the user control and ensures the timestamp reflects a real-world action at that moment.

• How to implement: Create a UI Action on the desired table, and in the UI Action's script, you can use the same server-side code to set the date. For instance:

// Server-side UI Action (on click of "Set to Now") 
current.start_time = new GlideDateTime(); 
current.update(); 
// save the change immediately 

In this script, when the user clicks the UI action, the current record's start_time gets set to the current date/time and then update() saves it. Using current.update() in a UI Action is acceptable because the action is explicitly initiated by the user and they expect the record to save. (This is different from a Business Rule where saving inside the rule can cause a loop; here the update is the final outcome of the button click.)

• Client-side alternative: If you wanted, you could also set the date on the client side using a client script in the UI Action (for example, using JavaScript new Date() to get now and setting a form field), then have the user save the form. However, using server-side GlideDateTime in the UI Action ensures the time comes from the server (which is authoritative and consistent).

• Benefits: UI Actions are visible to users and can be documented as part of the process (e.g., "click this button to record the start time"). They don't run unless clicked, so they won't unexpectedly update records. They are great for optional or on-demand updates.

  
  

Using Flow Designer for Automatic Date Setting

Flow Designer is ServiceNow's modern low-code tool for building workflows and automation. Instead of writing script, you configure a flow with triggers and actions. To set a current date in a field, you can create a flow triggered by a record event, then use a ServiceNow provided action to set field values.

• When to use: Use Flow Designer if you prefer a configuration-over-code approach, or if the requirement is part of a larger automated process. For example, if you want to set an "Approved Date" when a request is approved, you might already be using a flow for the approval process, in which you can add a step to update the record's date field. Flows are also useful for orchestrating multi-step logic that might be cumbersome to do in a single Business Rule script.

• How to implement: In Flow Designer, you would create a flow with a Trigger like "When [Table] is updated (or inserted)" with conditions (e.g., state changes to Closed). Then add an Action step, such as "Update Record". In the Update Record step, specify the field (e.g., resolution_time) and set its value. Flow Designer typically provides options to set the field to a specific value or to use a dynamic value. For current date/time, you might use the "javascript:gs.nowDateTime()" as a dynamic default, or use a script step to generate new GlideDateTime(). In recent releases, Flow has a Data Pill for "Created" or system dates, but if not, a script step can fill the current date. The flow might look like:

  • Trigger: Incident record updated where state changes to Closed.

  • Action: Update Record (Incident) – set Resolution Time to "@{}" (some method to get current date, perhaps via a script logic or available variable).

  Because Flow Designer runs server-side actions, the result is similar to a Business Rule but achieved through configuration. The flow engine will handle executing after the record change, and it will update the field accordingly.

• Benefits: The main advantage of flows is readability and maintainability. Non-developers or admins can easily see that "when X happens, the flow sets Y field to current date". It's also less prone to certain script mistakes (like infinite loops) because the flow is transactional and you have to deliberately set the trigger and updates. Flows also allow for more complex operations (like waiting, additional tasks, etc.) without writing a lot of code. The downside could be that flows run slightly after the fact (comparable to Async business rules in that they don't block the form submission), so if you need the field to be set instantly before other logic, a Business Rule might still be needed. However, for most use cases (like stamping a date on closure or assignment), the slight delay is negligible and the outcome is the same.

  
  

In summary, while Business Rules are a classic and powerful way to fetch and set the current date on records, UI Actions and Flow Designer provide alternate paths that might be more suitable for certain situations. UI Actions shine in user-driven moments, and Flow Designer is excellent for building out a process with minimal code. As a developer, it's beneficial to choose the right tool for the job: if a date needs to be set behind the scenes on every record change, a Business Rule works well; if it’s part of a larger workflow or a user-controlled action, consider Flow or UI Action respectively.

Conclusion

Fetching the current date in a ServiceNow Business Rule is a fundamental technique that enables dynamic and automated data handling on the platform. To do this effectively, remember the following key takeaways and best practices:

• Use the right method for the job: ServiceNow offers gs.nowDateTime(), GlideDate, and GlideDateTime to get the current date/time. Use GlideDate for date-only needs and GlideDateTime for date-time. gs.nowDateTime() can be used for quick assignments, but leveraging GlideDateTime is often more robust (especially in scoped apps or when doing calculations).

• Choose the appropriate Business Rule type: Before Business Rules are ideal for setting a field on the current record (no extra update needed). After/Async rules are better for using the current date in related actions or logging, without modifying the current record's just-saved data. Avoid updating the current record in After rules to prevent recursive triggers.

• Avoid infinite loops and redundant saves: Do not call current.update() inside a Business Rule unless absolutely necessary. If you do, ensure you've designed the logic to not run repeatedly on the subsequent update. Typically, setting a flag or using a condition can prevent re-entry. In many cases, you can refactor the logic to eliminate the need for this call (for example, by using a Before rule or a flow).

• Leverage alternatives when suitable: If a requirement can be met with a Flow Designer flow or a UI Action, don't hesitate to use those instead of scripting a Business Rule. They can simplify maintenance and make the intention clearer. For instance, use a flow for post-update processing or a UI action for user-initiated date stamping.

• Test and verify time zone handling: After implementing the date logic, verify that the date/time stored is correct. Check a scenario with different user time zones if applicable, to ensure that using gs.nowDateTime() or GlideDateTime meets your needs (ServiceNow will handle conversion to UTC for storage, but make sure the displayed values to users are as expected). If consistency is critical, use GlideDateTime throughout for comparisons and calculations.

  
  

Next Steps: As a developer looking to optimize Business Rules, you should practice writing a simple Business Rule that uses these date-fetching methods. Try creating a Before Insert rule on a sample table that sets a date field to new GlideDateTime() and observe the result.

Experiment with GlideDate vs GlideDateTime to see the difference in stored values (one will include time, the other will not). Additionally, review your existing Business Rules in your ServiceNow instance: identify any that manually call current.update() or might be doing redundant work, and consider refactoring them following the best practices outlined above.

You can also explore the ServiceNow developer documentation for GlideSystem, GlideDate, and GlideDateTime for more advanced methods (such as date arithmetic, difference calculations, or formatting options) to further enhance your scripts. Finally, if you haven't already, try out Flow Designer by replicating one of your Business Rule use cases as a flow — this will give you perspective on when a no-code solution might be advantageous.

By understanding these concepts and utilizing the appropriate techniques, you'll be able to effectively fetch and use the current date in ServiceNow Business Rules (and beyond), leading to more reliable and maintainable applications. With these tools in hand, ServiceNow developers can ensure date fields are always up-to-date and automate time-based logic with confidence.