Catalytic is now PagerDuty Workflow Automation

Apply entry validation to fields

PagerDuty Workflow Automation fields always have a field type. For example, a field with the type “Text” accepts all alphanumeric characters, and the type “Integer” only accepts whole numbers. To add your own custom validations, you can add entry validation when you configure a field.

Safari browser bar
 

How entry validation works

Entry validation will prevent or restrict a user from submitting a form or task when a field has incorrect data. Entry validation only works on Text, Integer, and Decimal field types.

For example, you can restrict a field by length, values, or whether it matches a pattern. Each field type has its own unique restrictions available, and each field can a maximum of 3 entry validations.

How to add entry validation to a field

You can add entry validation from the configure field page, such as an Instance Field or form field. Entry validation works for any text, integer, or decimal field.

  1. Choose a Workflow, this will open the Workflow detail page.
  2. Select in the upper-right corner to get to the Workflow Builder page.
  3. Click open the Triggers and Fields section to head to your Instance Fields.
  4. Select Add a Field. Scroll to the middle and look for Entry Validation.

    screen readers look here
  5. Select Add a Validation under the Entry Validation section.
  6. Select the entry validation type from the drop down list, then enter the value.
  7. Optionally add an error message under the Error Message section.

Here’s an example of the process for a text field:

Safari browser bar
 

Add text field validation

There are three validation types for text fields:

  • Max length: Entries equal to or less than the max length are accepted.
  • Min length: Entries equal to or greater than the min length are accepted.
  • Pattern: You can set regex patterns and validate more complex entries. Only entries that match the pattern rules are accepted.

Min and max length validation must be set as an integer, and patterns must be valid regex. For more on patterns, see How to use pattern validation.

💡   Tip: It’s recommended to always add a custom error message when using the pattern validation, as the default error message will include the actual regex pattern used. Learn more.

Add integer and decimal validation

There are three validation types for integer and decimal fields:

  • Maximum: Any number equal to or less than the maximum is accepted.
  • Minimum: Any number equal to or greater than the minimum is accepted.
  • Multiple Of: Only multiples of the value are accepted.

💡   Tip: Keep negatives in mind when setting up restrictions. To restrict entries to positive numbers, set the minimum to 0. Multiple of applies to negative numbers, for example, -4 is an accepted multiple of 2.

Add pattern validation

The pattern validation is based off of Regular Expression (regex). It uses JavaScript’s native regex feature.

Regex is a complex search language used to search and match text. A regex pattern, like ^.+@[^\.].*\.[a-z]{2,}$ is like saying “Find all text with an @ symbol, a .com at the end, and is more than 2 character” in a single “expression”.

To learn more about pattern validation, check How to use pattern validation article.

Add expression validation

With expression validation, you can now set even more powerful, complex validation rules for your fields. The expression uses a Javascript syntax similar to the Field: Field formulas action, which means you’ll need familiarity with Javascript.

For example, you could write the expression (startsWith("SKU", this), to restrict entries to anything starting with SKU, or it could be more complex, ((startsWith("SKU", this) or (startsWith("#", this)), which restricts entries to anything starting with SKU or #

screen readers look here

Expression validation is available on all field types. You can add expression validation by selecting Expression next time you add entry validation. To learn more about expression validation, check the expression validation article.

How to create an error message

You can set a custom error message. There are also default error messages if no error message is set. To add an error message, fill in the Error Message field. This can be any alphanumeric characters.

The default error messages are:

  • Max length: Should NOT be longer than X characters
  • Min length: Should NOT be shorter than X characters
  • Pattern: Should match pattern X
  • Maximum: Should be <= X
  • Minimum: Should be >= X
  • Multiple of: Should be multiple of X

If no custom error message is used, then each error message will appear contextually based on a user’s entry. For example, as they enter text, it may display the Min length error at first, then the max length error. When a custom error message is used, it is used in all cases, and the max or min length messages do not show contextually.

Always set custom error messages when using patterns

We recommend always setting a custom error message when using the pattern entry validation on text fields. This is because the default error message for the pattern will include the actual regex pattern used, which most users will not understand.

screen readers look here

Add more context using emojis

Emoji work within error messages, and can be a fun way to add more context and readability. Check out Emojipedia for a list of all universal emoji symbols. ⚠️, 🚫, 🛑, and ☑️ are fun and commonly used.

How to test your validation

As you create your entry validation, enter values into the Default Value field to test the validation out. Any entry validation you add, even before you select , will apply to the Default Value field.

This is a great way to check any complicated pattern validation.

screen readers look here

Entry validation in tables

Tables also display and reflect entry validation. If you enter or edit cells directly, upon hitting Enter, a red badge appears when the entry does not meet the validation. Flagged entries are not saved.

Safari browser bar
 

The full validation appears when you select on a cell and edit it directly.

How to use pattern validation

The pattern validation is based off of Regular Expression (regex). It uses JavaScript’s native regex feature.

Regex is a complex search language used to search and match text. A regex pattern, like ^.+@[^\.].*\.[a-z]{2,}$ is like saying “Find all text with an @ symbol, a .com at the end, and is more than 2 character” in a single “expression”.

There are many commonly used regex patterns that are useful and practical for all users, but regex is a complicated scripting language and there may be unpredictable outcomes when making changes. For more on regex, see Mozilla’s MDN web documentation.

Commonly used patterns

You can get started with patterns right away using some pre-made examples. For a resource of pre-made patterns, browse the Regular Expression Library. Always test a pattern before using it live, there may be certain entries that unintentionally pass the validation. You can test validation from the configure field page.

To create your own custom patterns, it’s necessary to learn the regex language. See Mozilla’s MDN web documentation for more.

Email pattern

Pattern: ^.+@[^\.].*\.[a-z]{2,}$

Description: This expression requires an @, and a .com (or similar domain over 2 letters). The . cannot be directly after the @.

Example of accepted entries: erikamustermann@company.com, erika+mustermann@company.automation

Example of rejected entries: no@.com, no@p.e

International phone number pattern

Pattern: ^((\+)?[1-9]{1,2})?([-\s\.])?((\(\d{1,4}\))|\d{1,4})(([-\s\.])?[0-9]{1,12}){1,2}$

Description: This expression accepts + at the beginning of the number, and the use of (). It accepts spaces, ., - as separators between numbers. It limits the size to 30 characters. It does not accept alphabet characters. Number must end in a numeral.

Example of accepted entries: 1(555)5555555, +1-555-555-5555, 555.555.5555, (555) 555 5555

Example of rejected entries: phone number, 555 555 5555- 55555, +1+1.555.555.5555

US currency with or without comma pattern

Pattern: ^\$?([0-9]{1,3},([0-9]{3},)*[0-9]{3}|[0-9]+)(\.[0-9][0-9])?$

Description: This expression only accepts valid, positive integer or decimals. If a $ is used, it must be the first character. It accepts ,, but they must be properly formatted. It does not accept alphabet characters.

Example of accepted entries: $555,555.99, 1, 40000.55

Example of rejected entries: number, 44$44 5,55,555

Positive integers only pattern

Pattern: ^[1-9]+[0-9]*$

Description: This expression only accepts positive integers greater than 0. It does not accept any negative numbers, like -5.

Example of accepted entries: 33, 1, 40000

Example of rejected entries: number, -1 5.5, 0

Positive integers or decimals pattern

Pattern: (^\d*\.?\d*[1-9]+\d*$)|(^[1-9]+\d*\.\d*$)

Description: This expression only accepts positive integers or decimals greater than 0. It does not accept any negative numbers, like -5, or any improperly formatted numbers like 5.5.5

Example of accepted entries: 33, 1.44, 500.1

Example of rejected entries: number, -1 5.5.5, -4.5

Credit card number pattern

Pattern: ^((4\d{3})|(5[1-5]\d{2})|(6011))-?\d{4}-?\d{4}-?\d{4}|3[4,7]\d{13}$

Description: This expression accepts up to 16 numerals, optionally separated by a -. It only accepts specific CC number prefixes, including 4, 51–55, 6011, 34, or 37.

Example of accepted entries: 5100-5555-5555-5555, 6011-5555-5555-5555, 4555555555555555

Example of rejected entries: number, 51-55-5555 9999-9999-9999-9999

Get help with a problem or question

If something’s not working as expected, or you’re looking for suggestions, check through the options below.

I’m getting a “Schema is invalid” error when adding a validation

If the validation is formatted incorrectly, the system shows a general error message.

The Schema is invalid: data/maxLength should be integer error message indicates your Min or max length validation may have an alphabet character, a special character, or may be empty. Try deleting the current entry and reentering an integer.

The Schema is invalid: data/pattern should match format "regex" error messages indicates your pattern validation is not proper regex. Some common mistakes when formatting regex are:

  • Including spaces in the pattern, other than spaces you meant to add.
  • Not escaping characters.
  • Forgetting a ^ or $ when matching entire lines.
My default value is causing an error message

If you set entry validation, the default value must also adhere to the validation rules.

screen readers look here

If you want to add context or information to the field, try using the description or example fields.

Sorry about that. What was the most unhelpful part?









Thanks for your feedback

We update the Help Center daily, so expect changes soon.

Link Copied

Paste this URL anywhere to link straight to the section.