Dynamic Workflows are designed to help you achieve translation cost savings and faster time to market by intelligently routing your content based on parameters you choose.
Make your workflow dynamic by configuring Decision Steps and Workflow Branches.
Decision Steps and Workflow Branches
The Decision step is a workflow step that evaluates a string’s properties and automatically chooses between multiple steps to send them to. Think of a Decision step as a router step - they are different from other workflow steps in that:
- Can point to multiple steps: other workflow steps can only be followed by one workflow step. Decision steps can be followed by several parallel workflow steps
- Fully automated: users do not need to submit strings from a Decision step
Once a Decision step is defined, you can create multiple workflow branches from it. A workflow branch can consist of multiple workflow steps. This effectively allows you to have a single workflow that has the functionality of multiple workflows. Each branch can be configured to best translate the content that moves through it.
Decision steps can be used to support complex translation needs effortlessly and within the same workflow. Some examples:
- Send strings with high fuzzy scores to human translators (to leverage TM and SmartMatch) and strings with low fuzzy scores to machine translation (for cost savings and velocity).
- Split content by File URI to different agencies, then have all translated content reviewed together in an Internal Review step.
- Combine multiple different workflows for different locales into a single workflow.
You can have one Decision steps in a dynamic workflow, but it can be anywhere on the workflow - pre-translation, or post-translation. You can create as many workflow branches as you need.
If a string SmartMatches to a post-translation step in a dynamic workflow, the string will continue via the workflow branch it was routed to, until it is published.
Creating a Dynamic Workflow
- Go to Projects (select a project) > Gear Icon > Project Settings > Workflows
- Create a Workflow or scroll to the workflow you’d like to configure, then click Add Steps. The Workflow must contain a Translation step, at a minimum.
- Click on the + icon before or after any step to create the Decision step, or router.
- Select the Decision (New Branch) step type, then click Next.
- Enter a name for the step, then click Create. Note, strings will move to the next step in the workflow if no conditions are met.
- Next, create a second workflow branch to send strings to. Click on the + icon to begin building the second branch.
- Add a Branch step by choosing the Workflow step type.
- Standard step types are explained here.
- For Decision steps after a Translation step, you can choose to create an empty branch.
- Choose a step for this workflow branch to merge back into.
- Configure your new step.
- Repeat steps 4-6 to create as many workflow branches as you need
- Next, define the rules to route content to your workflow branches. Click on the Decision step to configure your rules.
- Decision steps contain the rules for sending strings to different workflow branches. A Decision step always has a default rule, which automatically sends strings to the first Translation step if no other rules apply. Click Add New Rule to define a new rule
- A rule consists of an action (where the string should go) and a condition (why it should go there). Choose a branch to send strings to, then choose a condition and define the value for it.
- Repeat steps 9-10 to define all your rules
- Click Save when you are done defining rules
- When you are done adding steps to the workflow, click Done on the workflow toolbar
Creating an Empty Branch
Empty branches can be created if the Decision step comes after the Translation step. It is specifically useful if the workflow contains one or more steps between the Translation step and Published. For example, if your workflow contains Translation, Edit, Review steps before it's Published, and translations submitted to the Edit step did not require an edit, you might be happy for those strings to bypass the Review step and go straight to Published. Simply add a Decision step after the Edit step, create an Empty Branch to merge to Published, and use the rule String was unedited in previous step
Rules
The following string conditions are supported for pre-translation and post-translation Decision steps. The example use cases below illustrate how each rule can be applied. They are intended as examples only and are not the only way to use a given rule. You can combine and configure rules in whatever way best fits your workflow.
File & project
| Rule | Description & example use case |
|---|---|
| File URI contains “…” | Checks if any file URI contains the specified text (partial match, case-insensitive) - "File123" matches "File123", "File1234", and "My File123", but not "File1". For example, route content from specific files or folders to a dedicated branch, such as sending marketing files to one team and legal documents to another. |
| File URI does not contain “…” | Same partial-match logic as above, but excludes matching file URIs from the branch. This is useful for sending everything except a certain file type or folder down a fast-track branch. |
| Project UID is in the list "…" | Enter a comma-separated list of project UIDs. You could use this to apply the same routing logic across a group of related projects, such as all projects for one product line. |
| Project UID is not in the list "…" | Enter a comma-separated list of project UIDs. For instance, exclude a specific set of projects from a shared routing rule. |
Locale
| Rule | Description & example use case |
|---|---|
| Source locale is in the list “…” | Use supported locale IDs, e.g., "fr-FR, pt-BR". This lets you route content originating from specific source locales to a branch with locale-specific handling. |
| Source locale is not in the list “…” | Use supported locale IDs, e.g., "fr-FR, pt-BR". For instance, send all source locales except a specified set down a particular branch. |
| Target locale is in the list “…” | Use supported locale IDs, e.g., "fr-FR, pt-BR". This is handy for routing target languages that need specialized handling, such as right-to-left languages or locales assigned to a particular vendor, to their own branch. |
| Target locale is not in the list “…” | Use supported locale IDs, e.g., "fr-FR, pt-BR". For example, apply a default branch to all locales except the ones handled in a different branch of the workflow. |
String keys, tags & variants
| Rule | Description & example use case |
|---|---|
| Has any of the string keys “…” | Checks if a string has at least one of the specified keys (partial match, case-insensitive) - "Key123" matches "Key123" and "Key1234", but not "Key1". You might use this to route strings by key naming convention, such as sending all "error_*" keys to a specialized linguist. |
| Has none of the string keys “…” | Partial match, case-insensitive. For instance, exclude strings with a certain key pattern from a branch. |
| Has any of the string tags “…” | Checks if a string has at least one of the specified tags (exact match, case-insensitive). This works well for routing strings flagged with tags from your CMS or API integration, such as "urgent" or "legal", to an appropriate branch. |
| Has none of the string tags “…” | Exact match, case-insensitive. For example, exclude tagged content from a branch's default handling. |
| Has any of the string variants "…" | Exact match, case-insensitive. Use this to route specific content variants, such as A/B test copy, to their own branch. |
| Has none of the string variants "…" | Exact match, case-insensitive. For instance, exclude variant content from default routing. |
Word count
| Rule | Description & example use case |
|---|---|
| String word count is greater than or equal to … | Enter the minimum string word count. This is useful for sending longer, more complex strings to human translators. |
| String word count is less than … | Enter the maximum string word count. For example, send short strings to machine translation for speed and cost savings. |
| Job word count is greater than or equal to … | Enter the minimum job word count. You could use this to route large jobs to a vendor with more capacity. |
| Job word count is less than … | Enter the maximum job word count. For instance, keep smaller jobs with a particular vendor. |
Repetition
| Rule | Description & example use case |
|---|---|
| String is a repetition | Identifies strings whose source text appears multiple times within the same set of content. Use this condition to route repeated strings through a different workflow branch. |
| String is not a repetition | Identifies strings whose source text appears only once within the same set of content. Use this condition to route first occurrences through your standard translation workflow while handling repeated strings separately. |
Pre-translation Decision steps
Pre-translation Decision steps have the following additional conditions:
| Rule | Description & example use case |
|---|---|
| Fuzzy estimate is equal to or greater than [0-100% threshold] | Checks the TM match percentage calculated at authorization time. For instance, route strings with high TM match scores to a lightweight review step, since they likely require little editing. |
| Fuzzy estimate is equal to [0-100% threshold] | Checks for an exact fuzzy-match percentage. You might use this to apply special handling to a specific fuzzy-match tier. |
| Fuzzy estimate is less than [0-100% threshold] | Checks the TM match percentage calculated at authorization time. For example, send low-fuzzy-score content to full human translation rather than machine translation. |
Note: The fuzzy estimate is generated at the time of authorization and can vary significantly from the fuzzy score. For example, repetitions and internal matches will have higher fuzzy estimates than the true fuzzy score.
Post-translation Decision steps
Post-translation Decision steps have the following additional conditions:
Edit history
| Rule | Description & example use case |
|---|---|
| String was edited in the previous step (no value required) | Checks whether the string was changed in the previous step. This is useful for sending translations that were changed by an editor to another review or QA step. |
| String was unedited in the previous step (no value required) | Checks whether the string was left unchanged in the previous step. For instance, fast-track unedited strings straight to publish, skipping a review step that isn't needed. |
Character limits
| Rule | Description & example use case |
|---|---|
| Translation length is greater than the character limit | Checks the translation length against the character limit defined when the string was uploaded to Smartling, or set manually in the dashboard. If no character limit is set, the rule is not applied and the string skips to the next workflow step. For example, send oversized translations back to an editor to fit UI space constraints, such as button labels or app store metadata. |
| Translation length is less than the character limit | Checks the translation length against the character limit defined when the string was uploaded to Smartling, or set manually in the dashboard. If no character limit is set, the rule is not applied and the string skips to the next workflow step. This lets translations that fit within limits continue straight to the next step. |
Source match
| Rule | Description & example use case |
|---|---|
| Translation matches source | Routes strings where the translated text is identical to the source text. For instance, flag likely-untranslated content, such as numbers, brand names, or placeholders, for a quick check, or auto-approve non-translatable strings. |
| Translation does not match source | Routes strings where the translated text differs from the source text. You could use this to send confirmed translations through the standard workflow path. |
Language quality estimation
| Rule | Description & example use case |
|---|---|
| Language quality estimation label is "…" | Available for accounts using Smartling's AI Toolkit. Select "High", "Medium" and/or "Low". For example, auto-publish high-confidence MT output and route "Low" scores to human review, reducing reviewer workload. |
| Language quality estimation label is not "…" | Available for accounts using Smartling's AI Toolkit. Select "High", "Medium" and/or "Low". This is useful for sending everything except a given confidence tier down an alternate branch. |
LQA
| Rule | Description & example use case |
|---|---|
| Highest severity LQA error is one of "…" |
Only applicable when the string's LQA errors were recorded using an MQM-compatible schema. Select one or more severities: Critical, Major, Minor, and/or Neutral. For example, route translations that the LQA Agent flags with Critical or Major errors to human review, while allowing translations with only Minor or Neutral errors to bypass review. This helps reviewers focus on the issues that have the greatest impact. |
| Highest severity LQA error is not one of "…" |
Only applicable when the string's LQA errors were recorded using an MQM-compatible schema. Select one or more severities: Critical, Major, Minor, and/or Neutral. This is useful for sending translations that the LQA Agent flags with anything other than Critical or Major errors straight to published (or a lightweight review step), while translations with Critical or Major errors are routed to a human edit step. |
| Has LQA errors | Routes strings that have at least one recorded LQA error. For example, catch any flagged translation for review before publishing, regardless of severity. |
| Has LQA no errors | Routes strings that were LQA reviewed and recorded as No LQA Errors. You could use this to fast-track clean translations to publish. |
| Not LQA reviewed | Routes strings that have not undergone LQA review. For instance, catch content that skipped LQA and route it back for review. |
Considerations
Order matters
Rules are executed in top-down order. Therefore, fuzzy estimate rules for repetitions should be first because they are considered to have the highest fuzzy %. Once a rule is executed, the strings for that rule will then be moved to the corresponding workflow segment and will not be evaluated against any following rules.
Example
Here are some rules for a dynamic workflow with 3 branches:
- Rule 1: Repetitions should go to the third branch
- Rule 2: All strings over 30 words should go to the second branch
- Rule 3: All strings under 30 words should go to the first branch
- Rule 3: All strings under 30 words should go to the first branch
- Rule 2: All strings over 30 words should go to the second branch
- Rule 1: Repetitions should go to the third branch
No wildcards
Wildcards are not supported.
All roads lead to Published
To ensure that content is translated correctly, all possible paths through a workflow must have exactly one Translation step and end at the same Published step. A workflow branch does not have to merge back to the Published step, but it must merge with a step that will eventually lead it to Published.