Introduction:

In this Part, we’ll show the process of integrating the child flow created in Part 1 into a Parent flow – the critical flow that you will be tracked for its history.

“If you missed Part 1, be sure to check it out for a complete guide on creating child flow in Power Automate.”

Step-by-Step Guide:

Integrate child flow to your Parent Flow:

Will continue with the remaining steps to incorporate the child flow and fully track the history of each run.

Step 1: Open Your Parent Flow and Add Essential Variables

To begin, open the existing flow you want to track. In this example, we’ll use an approval flow as the base for the parent flow.

Add the Following Variables:

1. Start Time Variable:
   To track the start time of the flow, create a variable called Start Time. Set its value to the current time using the utcNow() function.
   • This will capture the moment when the parent flow begins executing. It’s useful for tracking the duration of the flow later, especially when monitoring child flows.
     
2. End Time Variable:
   • Similarly, create a new variable called End Time. You will set this later to capture the moment when the parent flow finishes. This will help you calculate the total runtime of the flow, including any child flows.
     
3. Workflow Status Variable:
   Add another variable called Workflow Status. Initialize this with a default value of “Success”
   • This will track the overall status of the flow.
     

Step 2: Put Your Parent Flow Actions Inside the Scope Block

Once you’ve set up your variables, the next step is to organize your parent flow’s actions within a Scope block.

A Scope in Power Automate allows you to group multiple actions together. This makes your flow more organized and provides a clear structure for managing the flow’s execution. In this example, we’re putting all the parent flow actions inside the Scope block to track its execution clearly.

Steps to Implement:

1. Add a Scope Action:
   Search for and add a Scope action to your parent flow. This will act as a container for the actions that you want to track.
2. Include Flow Actions Inside the Scope:
   Drag and drop all the necessary actions (like sending approvals, updates, or other tasks) inside the Scope action.
   • This will help maintain a clean and structured flow, making it easier to manage and track.
     

Step 3: Create 3 Parallel Branches for Error Handling and Workflow Control

Now, we’ll introduce parallel branches to handle errors, timeouts, and other potential issues within the flow. This will give you greater control over the flow execution, especially when it involves critical operations like approvals.

1. Add the First Parallel Branch:
   • Click the “+” sign after the Scope action to add a Parallel Branch.
   • In this branch, add the “Set Variable” action to change the Workflow Status to “Failed”. This will help capture and track if the flow encounters any failure.
   • Action to Add:
     • Set Workflow Status Variable to Failed.
       
       

2. Configure the Run After Settings for the Set Variable Action:
   • In this step, configure the Run After settings for the Set Variable action.
   • Set the Run After condition to trigger if the Scope action fails or encounters an error. This will ensure that the Workflow Status is updated to “Failed” if any issues occur within the Scope.
   • Example Configuration:
     • Run After: Select has failed.
       
       
3. Repeat the Previous Step for Timeout Handling:
   • In the second parallel branch, add another Set Variable action to update the Workflow Status to “Failed” in case of a timeout.
   • Set the Run After condition for this action to trigger if the Scope action times out.
   • Example Configuration:
     • Run After: Select has timed out.
       
       
4. Add a Third Parallel Branch with a Dummy Flag:
   • Create another Parallel Branch, this time adding a Compose action.
   • Use this Compose action to set a dummy flag or placeholder. This flag can be useful for tracking or debugging the flow.
   • Action to Add:
     • Compose: Use a simple string like “Dummy Flag” to ensure this branch runs successfully.
   • Example Configuration:
     • Run After: Select has Successful and Skipped.
       
       

Step 4: Add a Scope Block Next to the Dummy Flag Compose Action

In this step, we will add a new Scope block next to the dummy flag compose action to ensure that the workflow history is captured and tracked.

1. Add a Scope Action:
   • Add a new Scope action next to the dummy flag Compose action.
     
2. Configure Run After Settings:
   • Set the Run After configuration for the new Scope action to trigger after the Compose (dummy flag) action completes. This ensures the scope runs after the previous actions have completed.
     
3. Add Workflow History Block:
   • Inside the newly added Scope, add a Compose action. Name this “Workflow History Block” and set its value to the expression workflow().
   • The workflow() function will return the details of the flow execution, including its start and end times, status, and other key properties.
   • Example Action:
     • Compose: Set value to workflow().
       

Step 5: Add the Child Flow Inside the Scope

Now, we’ll add the Child Flow inside the Scope to ensure that the parent flow properly runs and tracks the results of the child flow.

1. Add the Run a Child Flow Action:
   • Search for and add the Run a Child Flow action inside the newly added Scope.
   • After adding the Run a Child Flow action, select the child flow you want to include in the parent flow. Upon selection, it will automatically generate the configured inputs for the child flow.
     
2. Map the Workflow History Block:
   • In the Workflow obj input for the child flow, map the value to string(outputs('Workflow_History_Block')).
   • This step will pass the workflow history from the parent flow to the child flow for tracking purposes.
     
3. Map Remaining Inputs:
   • Map any remaining values to the child flow inputs from the dynamic content provided by the parent flow. This ensures that all necessary information is passed down to the child flow.
     

Accessing Child Flow in Different Environments:

For Same Environment:

• If you want to use the child flow in a different solution within the same environment, simply follow the same steps as you would to “Integrate child flow to your Parent Flow”.
• You will be able to see the child flow name in the “Run a Child Flow Action”

For Different Environment:

• To use the child flow in a different environment, you can export the entire solution as a .zip file. This file can then be uploaded to another environment or shared directly via the Power Automate Platform.
• After importing the solution into the new environment, ensure the connections are properly configured.
• Once the connections are verified, you can follow the same steps to “Integrate child flow to your Parent Flow”, and the child flow name will appear in the “Run a Child Flow Action”

Conclusion:

By following these steps, you’ve successfully created a Flow in Power Automate that tracks the history of its execution, incorporates child flows, and manages error handling. This setup provides transparency and ensures that all flow statuses are logged into your SharePoint or Dataverse, whether they succeed or fail.

Introduction:

In today’s digital landscape, organizations increasingly rely on automated workflows to enhance efficiency and streamline processes. However, as these workflows grow in complexity, tracking their execution history becomes essential for ensuring reliability and facilitating troubleshooting.

This blog explores a powerful approach to logging workflow running history using child flows in Power Automate. By leveraging child flows, users can capture critical data such as flow names, statuses, and execution URLs, storing this information in SharePoint or Dataverse tables for easy access and analysis.

In this Blog Series, you will be briefly seeing these topics in two parts:

• Part 1: Step-by-Step Guide — Creating a child flow to capture the necessary data for tracking your workflow execution history
• Part 2: Step-by-Step Guide — Integrating Child flow to the Parent Flow & How to Access this child flow as a reusable template across the different projects or Teams.

In this Part, you will introduce the concept of creating a child flow to get the necessary data.

Prerequisites:

• • SharePoint or Dataverse: Ensure you have access to either SharePoint or Dataverse to store and manage your data.
  • Power Automate: A valid account to access Power Automate for creating and managing your workflows.

Step-by-Step Guide:

Now, let’s dive into the detailed process for creating flows in Power Automate.

Setting Up in SharePoint or Dataverse

1. Create a List or Table named “Log Workflow Histories.”
2. Add the Following Columns:

Creating a Child Flow:

1. Access Power Automate at Power Automate.
2. Select “Solutions” from the left navigation pane.
3. Open Your Existing Solution or create a new one by clicking “New Solution.”
4. Create a Child Flow by navigating to:
   • All > New > Automation > Cloud Flow > Instant.
     

Step 1: Provide a Flow Name and Select the Manual Trigger

Choose a descriptive name for your flow that clearly indicates its purpose. This helps in identifying the flow later.

Step 2: Set Inputs in the Manual Trigger

Input Source: The inputs for this flow will be provided by the parent flow. Ensure that the following inputs are configured to receive data from the parent flow:

• Input 1: Workflow Object (Type: Text)
• Input 2: Start Date and Time (Type: Text)
• Input 3: End Date and Time (Type: Text)
• Input 4: Workflow Status (Type: Text)

Step 3: Add a Compose Action to Convert the Workflow Object to JSON Format.

The Workflow Object we receive from the parent flow is in JSON format but is treated as a string in the manual trigger input. By converting it into a JSON object, we can easily extract specific information and manipulate the data as needed in subsequent steps of the flow.

• Add a Compose Action:
  • Click on “+ New Step.”
  • Search for and select “Compose.”
• Configure the Compose Action:
  • In the Inputs field of the Compose action, enter the following expression to convert the Workflow Object to JSON format: json(triggerBody()?['Workflow Object'])
    
    
    
    
• Name the Compose Action (Optional but Best Practice):
  • You can rename the action to something descriptive, like “Convert Workflow Obj to JSON.” In this example, I have named “Convert to Obj”.

Step 4: Add a Compose Action to Extract the Workflow Link

This Compose action allows us to isolate and extract the workflow link from the previously converted JSON object. This makes it easier to use the link in further actions within the flow.

• Add Another Compose Action:
  • Click on “+ New Step.”
  • Search for and select “Compose.”
• Configure the Compose Action:
  • In the Inputs field of this Compose action, enter the expression to extract the workflow link.
  • The expression would be: concat('https://make.powerautomate.com/environments/',outputs('Convert_to_Obj')?['tags']?['environmentName'],'/flows/',outputs('Convert_to_Obj')?['name'],'/runs/',outputs('Convert_to_Obj')?['run']?['name'])
    ‘Convert_to_Obj’ – replace it with the name of your previous compose action.
    

Step 5: Add another Compose Action to Extract the Flow Name

Please revisit Step 4 and replace the current expression with the following. Additionally, rename the Compose action to “Workflow Name.”

The Expression would be:outputs('Convert_to_Obj')?['tags']?['flowDisplayName']

The extraction from the workflow object is now complete. Next, it’s time to add the item to either a SharePoint list or a Dataverse table.

Step 6: Add an Item to SharePoint List

• Add a New Step:
  • Click on “+ New Step.”
  • Search for and select “SharePoint” from the list of connectors.
    
• Choose Action:
  • Select the action “Create Item.”
    
• Configure the Create Item Action:
  • Site Address: Choose the SharePoint site where your list is located.
  • List Name: Select the “Log Workflow Histories” list you created earlier.
• Map the Fields:
  Fill in the fields using the outputs from previous steps:
  • Workflow Name: Use the output from the “Workflow Name” Compose action.
  • Start Date and Time: Map this to the corresponding input from the manual trigger.
  • End Date and Time: Map this to the corresponding input from the manual trigger.
  • Workflow Status: Map this to the corresponding input from the manual trigger.
  • Workflow Link: Use the output from the Compose action that extracted the workflow link.
    

You can follow either Step 6 or Step 7 based on your chosen data source—SharePoint or Dataverse. If you’re using SharePoint, refer to Step 6 for adding an item to the SharePoint list. If you’re using Dataverse, follow Step 7 to add a row to the Dataverse table.

Step 7: Add an Item to Dataverse Table

• Add a New Step:
  • Click on “+ New Step.”
  • Search for and select “Dataverse” from the list of connectors.
• Choose Action:
  • Select the action “Add a Row.”
    
• Configure the Add a Row Action:
  • Table Name: Select the Dataverse table where you want to add the item (e.g., “Log Workflow Histories”).
• Map the Fields:
  Fill in the fields using outputs from previous steps:
  • Workflow Name: Use the output from the “Workflow Name” Compose action.
  • Start Date and Time: Map this to the corresponding input from the manual trigger.
  • End Date and Time: Map this to the corresponding input from the manual trigger.
  • Workflow Status: Map this to the corresponding input from the manual trigger.
  • Workflow Link: Use the output from the Compose action that extracted the workflow link.

Conclusion:

“In the first part, we’ve explored how to create the child flow. In the next part of this series, we’ll show you how to integrate this child flow into a parent flow and start capturing the history for your critical flows. “

Many consider workflow to be a necessary evil. But it is necessary, and I will make my case in this post. I highly recommend working through the requirements for workflow and including it in your initial site build or rebuild. However, not all of us have that luxury – and that’s okay. The great thing about workflow in Sitecore is that at the end of the day, it is just another field that can be modified like the others. This means that you can develop and apply workflow to Sitecore items at any point in your lifecycle via Powershell. 

Here are three reasons that I am a big advocate of implementing workflow. I would love to hear yours in the comments or on LinkedIn.

1. Scalability

Here is a common scenario: when building a website, workflow is deemed unnecessary and pushed to Phase 2 because there are only a few content authors. Other features and bugs continue to take priority over implementing workflow. Now you are a few years down the line and your organization has grown, or you have implemented features that require a new set of content authors to be trained. Suddenly this lack of workflow is a problem. 

An organization may not have any issue allowing all content authors to be administrators early in a Sitecore implementation. In fact, it is often viewed as the more efficient option if their authors are Sitecore savvy. It will save money on the workflow implementation, and the authors will not be limited to performing only certain actions. 

However, this model is not scalable. Businesses experience turnover and growth. It is unlikely that you will have the same people using Sitecore in a year that you do today. Making everyone an administrator is risky, and implementing even the most basic user roles and workflow will enable your organization to adopt Sitecore on a larger scale. 

2. Audit Trail

When you make a change to a page as an administrator, you just make the change and save. When you are using workflow and user roles, you use the “lock and edit” action that checks out and adds a new version of the page. This creates an audit trail of the editing history of that page:

An example of a Sitecore page that has 9 different versions created through workflow.

This history serves several purposes – the first being that it eliminates confusion. I have aided in many investigations when something unexpectedly changed on a page. No one knew who made the change or when it happened. Sitecore will show you which account last updated each item and when, but beyond that you must rely on the logs. Combing through the logs can be extremely time-consuming if you cannot pinpoint the day and time that the activity took place. If you have this editing history as shown above, you have a clear audit trail of what changed and when. 

Secondly, having this history can almost serve an “undo” function. It allows you to revert the page to a previous version if something went wrong with the most recent version. 

3. Ability to run automated publishing jobs

Let’s consider the case of an organization that has a lot of content but a small approval team. To make things easier on the approvers, they may elect to run an automated publishing job 1-2 times per 24 hours to publish all finalized content to the front end. The team would approve content throughout the day, publish what is needed to go live on the site immediately, and the automated job would publish the rest of the approved content on schedule. 

Automated publishing jobs are not possible unless you have workflow in place. The reason these jobs work is because they only publish approved content, not content that is in Draft or Waiting for Approval state. If there is no workflow at all, these jobs would publish all saved changes. This would potentially result in changes that were not ready to be user-facing going live on the front end. 

Applying workflow after implementation

The good news: if you have already implemented a site without workflow, it is simple enough to run a project to implement it and apply it to the items in your solution. You can apply basic workflow, or you can develop a custom workflow tailored to your organization and its needs.  

When the development is done, you can deploy the code to production and plan to run a Powershell script to apply the workflow at a time when it is most convenient for your team. This means that you can time the deployment and the “enabling” separately to ensure that your entire team is prepared. When you are applying workflow via script, you will likely be setting each item to the Approved state initially. The content team will need advance notice to ensure all recent changes are ready for production before the workflow changes are applied, since setting each item to Approved and publishing will push all changes to the front end. 

Summary

Workflow is a worthwhile investment. If it is not already in your solution, I hope it is an upcoming stop on your roadmap. If you are also passionate about workflow or have any other compelling reasons to add to this list, reach out to me and start a dialog on LinkedIn!

Introduction

If you haven’t heard, OpenAI released ChatGPT-4, the successor in a computational sense to GPT-3. Although slower at the moment, its capabilities have improved immensely. How much, you may ask? Well that is what I’m here to tell you. For context, I will be throwing some of the same questions at it I threw at GPT-3 in my previous blog post, so check that out if you’re curious. Starting just like last time, hey GPT! Describe yourself and how you could help consultants.

ME: Hey GPT, how would you explain yourself to a consulting agency in 4 sentences, focusing on how you could add value to technical and business consultants?

— GPT-3 —

Hello! I am a large language model trained by OpenAI. I am able to generate human-like text based on a given prompt or context. I can assist technical and business consultants by providing accurate and relevant information on a wide range of topics, as well as by generating reports, summaries, and other written materials. Additionally, I can help with data analysis and research, allowing consultants to save time and focus on their core competencies. Overall, I can add value to consulting agencies by providing high-quality, reliable support for their work.

— GPT-4 —

As a cutting-edge AI language model, I can quickly and accurately analyze large volumes of data and generate actionable insights, significantly increasing consultants’ efficiency and effectiveness. My ability to understand complex concepts and communicate them in simple, digestible terms enables consultants to deliver high-quality presentations and reports to clients. Furthermore, I can automate routine tasks such as data entry, research, and scheduling, allowing consultants to focus on strategic problem-solving and relationship-building. My versatility, scalability, and continuous learning capabilities can help your consulting agency stay ahead of the curve, adapt to industry trends, and deliver superior value to clients.

Notice first that GPT-4 is following my exact instructions. GPT-3 gave me 5 sentences, 6 if you count “Hello!”. GPT-4 got straight to the point, and only output 4. It also sounds like a consultant already!

GPT-4 Codes Anything

I asked GPT-3 to tell us about a for-loop. It gave an excellent description and examples that were accurate and useful. GPT-4 will be able to do something far more incredible. GPT-3 was limited in that it could only remember about 3,000 words. GPT-4 can remember 25,000. This means that you could paste large swaths of a project into it, and get back highly specific and relevant results for additional queries. Additionally, GPT-4 is much better at complex reasoning. So watch this:

ME: What version of Next.js are you familiar with?

GPT-4: At the time of my last training update in September 2021, Next.js 11 was the latest stable version.

ME: So you don’t know about the App directory, or server components.

GPT-4: React server components, in the experimental phase during my training, allow server-rendered architecture for better performance and lower bundle sizes. The App directory refers to the folder structure in React or Next.js projects, organizing components, pages, and resources.

While it has a hunch about how Next.js will enable server-side components, it has no clue about the App directory, giving us a generic description of what an app folder might contain if it was in a project. So watch this right here. I now paste the entire documentation for the app directory, plus the blog announcement for Next 13 into the chat. And then I ask this:

ME: So what is the app directory and what are server side components in next 13

GPT-4: In Next.js 13, the app directory is introduced to improve the organization of your application and make it easier to adopt Server Components. All components inside the app directory are React Server Components by default. This allows you to automatically adopt Server Components with no extra work and achieve great performance out of the box.

React Server Components allow developers to better leverage server infrastructure. With Server Components, the initial page load is faster, and the client-side JavaScript bundle size is reduced. They enable you to keep large dependencies, sensitive information, and direct access to backend resources on the server side, resulting in improved performance for your application.

Server Components make writing a React application feel similar to PHP or Ruby on Rails but with the power and flexibility of React for templating UI. When a route is loaded with Next.js, the initial HTML is rendered on the server and then progressively enhanced in the browser. This allows the client to take over the application and add interactivity by asynchronously loading the Next.js and React client-side runtime.

In summary, the app directory is a new way to organize your Next.js application, making it easier to adopt Server Components, which are components that leverage server infrastructure for improved performance and flexibility.

Incredible. It was able to read and summarize the blog and documentation to answer my question.

Advanced Comprehension

Movie Summary

The best but perhaps most subtle change in GPT-4 is how well it can understand context and connect similar ideas. I pasted the Wikipedia entry on a movie released in 2022 and ask them to summarize it. I asked them both beforehand and confirmed: they did not train on this movie.

ME: Summarize the plot of Doctor Strange: Multiverse of Madness

GPT-3: In Doctor Strange: Multiverse of Madness, America Chavez and a version of Stephen Strange travel through different universes searching for the Book of Vishanti while being pursued by demons. They end up on Earth-616 where they seek the help of Wanda Maximoff, who is revealed to be behind the attacks. Maximoff has been using the Darkhold to control Chavez’s powers in order to reunite with her children, but Strange and Chavez team up to stop her, resulting in a multiverse-shaking showdown. The film ends with the surviving sorcerers continuing to train and Strange developing a third eye as a result of using the Darkhold.

This summary reveals one of GPT-3’s biggest weaknesses: relevance. That America had been traveling with another Doctor Strange is true, but impacts the story in almost no capacity. Additionally, it is confusing to mention Earth-616 as a destination they reach when that is actually our earth, the one where all movies have taken place so far. Let’s look at what GPT-4 said.

GPT-4: Doctor Strange: Multiverse of Madness follows the journey of America Chavez and Doctor Strange as they navigate the multiverse, seeking the Book of Vishanti to counter the destructive effects of the Darkhold. Along the way, they face a powerful and misguided Wanda Maximoff, who seeks to control Chavez’s powers in order to reunite with her children. Strange and Chavez, with the help of allies, manage to confront and redeem Maximoff, ultimately destroying all copies of the Darkhold across the multiverse. The film ends with the surviving sorcerers rebuilding Kamar-Taj and continuing their training, while Strange faces new challenges in the form of an impending incursion.

Even if you have not seen this movie, I can tell you this summary is much better. Besides being more technically accurate, this summary also gives a sense of the true character tension and struggle that the film will show. It also mentions details that actual matter, and leaves out ones that do not, like Doctor Strange developing a third eye.

PBI Writing

How about a more pertinent example? You need to write up a PBI. There is a component that shifts the page content when hovered over and it should not. Additionally, the component cannot be reached by the keyboard, it seems to get skipped over. Even worse, your WCAG developer is out for the week, and the rest of the team typically struggles to know where to start on ADA issues.

ME: I need a PBI written up. There is a component that shifts page content when hovered over it, and it should not. It also is not reachable by keyboard navigation. Write up the problem, and include acceptance criteria phrased in questions that can be answered with yes or no. Also, include in the description some possible reasons it may not be keyboard accessible. This will help investigation into solving the issue.

GPT-3:

Problem:

When hovering over a component on the page, the page content shifts, which is an unintended behavior. Additionally, the component is not reachable by keyboard navigation.

Description:

The component is likely not keyboard accessible because it may be missing an appropriate tabindex attribute, or the role attribute may not be set to a proper value. Another possibility is that the component is implemented using non-semantic markup such as div or span elements instead of using the appropriate semantic elements such as button or input.

Acceptance Criteria:

1. Does the component stay in place when hovered over? (Yes/No)
2. Is the component reachable by keyboard navigation? (Yes/No)
3. Does the component have a proper tabindex attribute? (Yes/No)
4. Is the component implemented using the appropriate semantic markup such as button or input? (Yes/No)
5. Does the component have a proper role attribute set? (Yes/No)

This is…a start. I’d say this probably saves you only seconds of time, and AC #3 is concerned about implementation, which was not a specified concern and oversteps our ask.

GPT-4:

Title: Fix Component Hover-Shift Behavior and Ensure Keyboard Accessibility

Problem Description: We have identified a component within our application that exhibits an undesired behavior: when a user hovers their cursor over it, the page content shifts unexpectedly. In addition to this, the component is not reachable through keyboard navigation, which raises accessibility concerns.

Possible reasons for the lack of keyboard accessibility could include:

1. The component might not have a proper tabindex value assigned, or it might have a negative tabindex, causing it to be skipped during tabbing.
2. The component may be implemented using a non-interactive element (e.g., a div or span), which does not receive focus by default.
3. The component’s JavaScript event handlers might not be listening for or correctly handling keyboard events, such as ‘keydown’ or ‘keyup’.
4. There might be a CSS rule that is inadvertently hiding the component or making it non-interactive when accessed through keyboard navigation.

Acceptance Criteria: The following questions should be answered with a ‘yes’ or ‘no’ to determine whether the issue has been resolved:

1. Does the component no longer cause the page content to shift when the user hovers their cursor over it?
2. Is the component now reachable and interactive through keyboard navigation, specifically by using the ‘Tab’ key?
3. Can the user interact with the component using the ‘Enter’ and/or ‘Space’ keys, as appropriate for the type of component?
4. Does the component exhibit a visible focus state when accessed via keyboard navigation, indicating that it is currently the active element?

Upon addressing the issues described, the component should no longer exhibit any undesired shifting behavior and should be fully accessible through keyboard navigation.

Oh my. I might just paste this straight in and send the PBI off! Not only is the language much more professional and detailed, GPT-4 even comprehends proper accessibility rules and incorporates them in the AC. Notice too, how GPT-4 provides a title as well, which even though I did not request it, is obviously going to be part of any PBI.

GPT-4, The Sitecore Architect

I once built a client a custom field that involved lots of custom Javascript, HTML, and styling. Figuring out a way to inject the whole thing into a page item in Sitecore took some time. While I wrote a blog on that whole process here, why not ask GPT and see what happens? Given a vague and rather open-ended query, GPT-3 responded:

ME: I want to inject a custom javascript/html component into the fields section on a page item in sitecore. I’ll write some custom functionality using javascript, and when the user is done interacting with it I want it to save the data to a text field when the user presses a button. How would I go about doing this?

GPT-3

To inject a custom JavaScript/HTML component into a Sitecore page item’s fields section, you will need to create a custom field type in Sitecore. Here are the steps to create a custom field type:

1. Create a new Sitecore item under the /sitecore/system/Field types node in the content tree. This item will represent your custom field type.
2. In the item’s Control field, specify the path to your JavaScript/HTML component.
3. Create a new class that inherits from the Sitecore.Data.Fields.FieldControl class. This class will be responsible for rendering your custom component in the fields section.
4. Override the GetControl() method to return an instance of your JavaScript/HTML component.
5. Implement the necessary logic in your JavaScript code to interact with the Sitecore API and save the data to the text field when the user clicks the save button.
6. Finally, add your custom field type to the template of the page item where you want to use it.

Once you have completed these steps, your custom field type should be available in the fields section of the page item, and the data entered by the user should be saved to the text field when the user clicks the save button.

That’s…doing something. It certainly isn’t the whole thing, and I’m not sure where exactly the Javascript I talked about went. Well, GPT-4 saves me a week:

GPT-4

To inject a custom JavaScript/HTML component into the fields section on a page item in Sitecore, you need to create a custom Sitecore field type. Here’s a step-by-step guide to help you achieve this:

1. Create a new class for the custom field type:

Create a new class that inherits from Sitecore.Shell.Applications.ContentEditor.Text, which represents a text field in Sitecore. Add a reference to Sitecore.Kernel.dll if required.

using Sitecore.Shell.Applications.ContentEditor;

public class CustomJSComponentField : Text
{
     // We will add the implementation here.
}

 

2. Override the DoRender method:

Override the DoRender method to add your custom HTML and JavaScript to the field rendering.

protected override void DoRender(HtmlTextWriter output)
{
    // Call the base DoRender method to render the default text field.
    base.DoRender(output);// Add your custom HTML/JS component.
    output.Write("<div id='custom-component'></div>");
    output.Write("<script src='/path/to/your/custom-script.js'></script>");
}

 

3. Register the custom field type:

In your Sitecore solution, find the /App_Config/FieldTypes.config file, and add the new custom field type to the <fieldTypes> section.

xml

<fieldType name="CustomJSComponentField" type="YourNamespace.CustomJSComponentField, YourAssembly" />


Replace “YourNamespace” and “YourAssembly” with the appropriate values for your solution.

4. Create a new Template Field:

In Sitecore, create a new template field and set its type to CustomJSComponentField. This will make your custom field type available for use in your templates.

5. Implement the custom JavaScript functionality:

Create a custom-script.js file with your custom functionality. For example:

document.addEventListener("DOMContentLoaded", function () {
     const textField = document.querySelector(".scContentControl");
     const customComponent = document.getElementById("custom-component");
     const saveButton = document.createElement("button");saveButton.innerText = "Save";
     customComponent.appendChild(saveButton);// Add your custom logic here.

     saveButton.addEventListener("click", function () {
          // Save the data to the text field.
          textField.value = "Your data to save";
      });
});

 

This script adds a “Save” button to your custom component, and when the user clicks on it, it saves the data to the text field. Update the script to include your custom functionality as needed.

Once you’ve completed these steps, the custom JavaScript/HTML component should be injected into the fields section on a page item in Sitecore. When the user interacts with your custom component and presses the “Save” button, the data will be saved to the text field.

If you don’t have time to read the other blog I’ll tell you — it is correct about these steps, it’s almost exactly what I had to do. All of that, based on one paragraph. It’s magic.

Closing

GPT-3 was already an incredible and world-changing tool, GPT-4 continues along that path. The additional complexity of tasks and context it can handle allow for even more improvements in daily workflow. If you don’t use it yet, I cannot recommend it enough. And if you aren’t sure how to start, I’ve got a guide on using it to develop!

Bonus Round

I’ve pasted in this article into GPT-4, and I’ve asked it to give me a meta description and focus key phrase.

Meta Description: Discover the impressive capabilities of ChatGPT-4, the successor to GPT-3, and see how its improved performance is nearly magical

Focus Key phrase: ChatGPT-4 Capabilities

And yes, I used them. That’s all for now, check back in for my next post on more tricks and efficiencies with ChatGPT!

Apache Airflow is an open-source tool to programmatically author, schedule, and monitor workflows. It is one of the most robust platforms used by Data Engineers for orchestrating workflows or pipelines. You can easily visualize your data pipelines’ dependencies, progress, logs, code, trigger tasks, and success status.

With the help of Apache Airflow  and Python we can easily create workflows without using underlying infrastructure for scalability and security.

What is workflow?

In simple terms, workflow is a sequence of tasks. Workflow will be started on schedule or triggered by and event. Workflow is used to handle big data processing pipelines.

Workflows based on Airflow have tasks where outputs are inputs for other tasks. In Workflow loop back is not possible because the output of every step is an input in the next step.

Typical Example of Workflow

In Airflows, these workflows are represented as Directed Acyclic Graphs (DAG).

What is DAG?

A DAG is defined in a Python script, which represents the DAGs structure (tasks and their dependencies) as code. DAG is nothing but the collection of tasks that you want to run one after other. Each node in the graph is a task. In other words when we decide the workflow, we need to think about what work should be divided in small tasks.

The graph is enforced to be acyclic so that there are no circular dependencies that can cause infinite execution loops

A DAG has no cycles, a DAG is a data pipeline in Apache Airflow. So, whenever you read “DAG”, it means “data pipeline”.

Valid Workflow of DAG

Invalid Workflow of DAG

What is Node?

Node is nothing but an operator. An operator is a collection of logic of what we want to achieve in DAG. (For example: If we want to write a DAG in Python we will have a Python Operator, similarly if we want to execute the script in bash operator, then there will be a Bash Operator.)

What is the Need for Apache Airflow in Trending Technologies?

1. Workflow Monitor
   • Monitoring plays is a crucial role in data management. Apache airflow allows us to monitor the workflows. It ensures that your systems and processes are performing as expected. Monitoring capabilities is really important for companies that use Airflow to orchestrate and schedule their long-running tasks.

2. Scheduler

• • Scheduler is very important in data management. Data engineers cannot keep an eye on each other as well as every workflow. With the help of Scheduler we can schedule a Workflow then trigger the task instances once their dependencies are complete. Behind the scenes, the scheduler spins up a sub-process that monitors and stays in sync with all DAGs in the specified DAG directory. Once per minute, by default, the scheduler collects DAG parsing results and checks whether any active tasks can be triggered.

3. Monitoring UI

• • Airflow’s native UI lets you visualize your DAG and task statuses. In addition, you can monitor a few native metrics from this UI, but there is a lot of room for improvement (we’ll get into that later). This can help you do some light monitoring and troubleshooting for you DAGs.

4. Rest API

• • Airflow’s API allows you to create workflows from external sources, and to be data product on top of it. The rest API allows you to use the same paradigm used to build pipelines, to create asynchronous workflows, such as custom machine learning training operations.

5. Alerting Systems

• • Airflow provides a default alerting system on failed tasks, email is the default, but alerting through Slack can be set up using a call back and the slack operator.

Amazon Web Services (AWS) provides a similar type of service called Amazon Managed Workflows for Apache Airflow (MWAA). So, let’s start with MWAA and see how we can monitor workflows.

Prerequisites:

• S3 Bucket
• VPC Network
• Workflow Environment

You will need to…

• Create an S3 Bucket in which you can upload Python code
• Create a VPC and Subnets
• Create a workflow in MWAA

The dashboard of Apache Workflow should look like what is shown below.

Create a Python code accordingly to monitor workflow. Following sample Python code, you will upload to a S3 Bucket.

from datetime import datetime

# The DAG object; we’ll need this to instantiate a DAG

from airflow import DAG

# Operators; we need this to operate!

from airflow.operators.python import Python Operator

from airflow.operators.dummy import DummyOperator

#from tasks.get_configs import get_configs

#from tasks.get_targets import get_targets

#from tasks.push_targets import push_targets

def print_hello():

return “Hello World”

 

dag = DAG (‘hello_world’ ,description=’testing’,

schedule_interval=’0 12  * * *’,

start_date = datetime (2021 ,1,1), catchup=False)

dummy_operator = DummyOperator(task_id=’dummy_task’, retries=3, dag=dag)

hello_operator = PythonOperator(task_id=’hello_task’, python_callable=print_hello, dag=dag)

dummy_operator >> hello_operator

Once done we will hit the Airflow UI and we will get the following monitoring dashboard of Airflow. Here we can schedule a workflow monitor our workflow and manage alerting.

How Can Perficient Help You?

Perficient is a certified Amazon Web Services partner with more than 10 years of experience delivering enterprise-level applications and expertise in cloud platform solutions, contact center, application modernization, migrations, data analytics, mobile, developer and management tools, IoT, serverless, security, and more. Paired with our industry-leading strategy and team, Perficient is equipped to help enterprises tackle the toughest challenges and get the most out of their implementations and integrations.

Learn more about our AWS practice and get in touch with our team here!

Welcome to my Mini-Series! In my Mini-Series, I take you from beginning to end in creating a simple workflow from scratch. Use this Mini-Series to help empower your business with workflow!

• Implementing Workflow in Sitecore: A Mini-Series Part 1 – Overview

• Implementing Workflow in Sitecore: A Mini-Series Part 2 – Workflow States

• Implementing Workflow in Sitecore: A Mini-Series Part 3 – Applying Workflow

• Implementing Workflow in Sitecore: A Mini-Series Part 4 – User Permissions

• Implementing Workflow in Sitecore: A Mini-Series Part 5 – Versioning

• Implementing Workflow in Sitecore: A Mini-Series Part 6 – Archiving Old Versions

• Implementing Workflow in Sitecore: A Mini-Series Part 7 – Speeding Up The Process

The benefits of implementing workflow in Sitecore does not come without its cons. As with any business process, the more stop gates you add to getting your content live makes the work more cumbersome. In our Simple Workflow, you have to lock and edit to create a “Draft” item. After saving your changes, you then have to submit your item for approval. After it is approved, you then have to publish the item. Imagine if you created a new page and added 15 new components that each come with their own new data source items. You would have to submit the page item and each of the 15 data source items individually. Doing that multiple times can significantly hinder a content author’s ability to produce content in a timely fashion. In this blog post, we will be creating PowerShell scripts that content authors can run in the Content Editor that will do all the leg work for them.

PowerShell Scripts for Authors

$currentItem = Get-Item .

Get-ChildItem -Recurse -Path $currentItem.FullPath -WithParent | Where-Object { $_."__Workflow State" -eq '{<Insert the Guid of the Draft State in your workflow>}' } |
        ForEach-Object {
            Write-Host "Submitting for approval:" $_.Name
            $_.Editing.BeginEdit()
            $_.Fields["__Workflow State"].Value = "{<Insert the Guid of the Awaiting Approval State in your workflow>}"
            foreach ($version in $_.Versions.GetVersions($true))
            {
                if($version.Locking.IsLocked())
                {
                    $version.Editing.BeginEdit()
                    $version.Locking.Unlock()
                    $version.Editing.EndEdit()
                }
            }
            $_.Editing.EndEdit()
        }

Insert your “Draft” state and “Awaiting Approval” state guids where appropriate in the script above. This script will take the current item you are running it on and move the current item and its children that are in the “Draft” state into the “Awaiting Approval” state. It will also unlock the items that have changed states.

Then save it in the following location below to make it accessible in the Content Editor.

Saving the script in this folder structure makes it possible for you to access this script on any given item by right clicking it. Below is what this looks like:

PowerShell Scripts for Approvers and Admins

$currentItem = Get-Item .

Get-ChildItem -Recurse -Path $currentItem.FullPath -WithParent | Where-Object { $_."__Workflow State" -eq '{<Insert the Guid of the Draft State in your workflow>}' } |
        ForEach-Object {
            Write-Host "Submitting for approval:" $_.Name
            $_.Editing.BeginEdit()
            $_.Fields["__Workflow State"].Value = "{<Insert the Guid of the Approved State in your workflow>}"
            foreach ($version in $_.Versions.GetVersions($true))
            {
                if($version.Locking.IsLocked())
                {
                    $version.Editing.BeginEdit()
                    $version.Locking.Unlock()
                    $version.Editing.EndEdit()
                }
            }
            $_.Editing.EndEdit()
        }

Insert your “Draft” state and “Approved” state guids where appropriate in the script above. This script will take the current item you are running it on and move the current item and its children that are in the “Draft” state into the “Approved” state. It will also unlock the items that have changed states. Save this script in the same folder location as the previous script. It will be accessible in the same way too.

Preventing Authors from Submitting and Approving Content via PowerShell Script

Access the Security Editor and update the permissions on the Author role. Deny Read access to the PowerShell script that allows content authors to move items from the “Draft” state to the “Approved” state. This will hide the option to run these scripts in an item’s context menu.

Conclusion

This blog post concludes the mini-series! I hope it was helpful in explaining how to implement workflow in Sitecore for your company. Feel free to leave comments below if you have any questions!

To prevent performance issues for content authors in the Content Editor, Sitecore recommends keeping no more than 10 versions of items. In this blog post of my mini-series, I will go over how to perform an automated cleanup of old, outdated item versions while retaining them in the Archive for historical record. Old versions found in the Archive can be restored for later use if need be.

The PowerShell script

$tenantItem = Get-Item -Path 'master:<insert path to your tenant here>'
$versionsToNotArchive = 10
$archive = [Sitecore.Data.Archiving.ArchiveManager]::GetArchive("archive", $tenantItem.Database)

Get-ChildItem -Path $tenantItem.FullPath -Recurse -WithParent |
    ForEach-Object {
        $versionsNotArchived = 0

        $itemVersionCount = $_.Versions.Count
        if ($itemVersionCount -gt $versionsToNotArchive) {
            $itemVersions = $_.Versions.GetVersions($true) | Sort-Object {[int]($_.Version -replace '(\d+).*','$1')} -Descending
            foreach ($itemVersion in $itemVersions){
                if ($itemVersion.Fields["__Workflow State"].Value -eq "{<Insert the Guid of the Approved State in your workflow>}" -AND $versionsNotArchived -lt $versionsToNotArchive){
                    $versionsNotArchived += 1
                }
                else {
                    if ($itemVersion.Fields["__Workflow State"].Value -eq "{<Insert the Guid of the Approved State in your workflow>}" -AND $versionsNotArchived -ge $versionsToNotArchive) {
                        Write-Host "archiving version" $itemVersion.Version "of" $_.FullPath
                        $archive.archiveVersion($itemVersion)
                    }   
                }
            }
        }
    }

Create a PowerShell script in PowerShell ISE. Copy and paste this script above into your new file. You will need to insert the path to your root folder in the first line of the script. You will also need to insert the guid of the “Approved” state item of your workflow in the for loop twice.

Let’s dissect exactly what this script does with an example. Let’s say the script is examining an item that has 15 versions in the Content Editor. Versions 1 – 14 are in the “Approved” state. Version 15 is in the “Draft” state. It will first order the item versions in array from highest numbered version to lowest numbered version. Think of this as ordering from the most recently made version to the oldest made version. It will then start counting from Version 15 down to Version 1 keeping track with the number of “Approved” versions the for loop has passed. After the 10th “Approved” version is reached, any “Approved” version after that will be sent to the Archive. In our example, item versions 1 – 4 will be sent to the Archive while item versions 5-15 will be kept for viewing in the Content Editor.

If you want to keep less approved versions in the Content Editor for your items, simply reduce the $versionsToNotArchive variable in the script above. Also note that the value for $_.Versions.Count is equal to the number of versions that exist for the item in the Content Editor NOT the total number of versions of an item that exist in the archive plus the number of versions that exist for the item in the Content Editor.

Automating the script on a schedule

Under /System/Tasks/Schedules, insert a new Schedule item and name it “Archive Old Versions Command Schedule”. Then populate its values with the below:

Replace the value found in Items with the path to the script we created earlier in the blog post. The Schedule value tells Sitecore to run my “Archive Old Versions” script once a week every Sunday until the end of time.

Restoring old versions from the Archive

To get to the Archive, navigate to the Sitecore Desktop and open the All Applications submenu. The Archive will be in there.

Simply click on the item and then click Restore. Note that restoring an item will restore ALL versions of the item back into the Content Editor unless if you click on a specific version to restore. It will later be cleaned up by our automated script, but you will be able to view the older versions for a short period of time.

A great benefit of implementing workflow in Sitecore is the ability to have multiple versions of your content automatically. Content authors will not have to manually configure new versions on their own. Workflow will do this for us behind the scenes. With versioning enabled, we will be able to…

• Revert a page and its content to a previous version easily without having to re-author the content from scratch
• Keep historical record of what a page looked like and easily surface what something looked like in the past
• Work on a new version of a page while keeping an older version live on the public-facing site

How does this work?

Sitecore will only publish the highest numbered approved version of a piece of content to the live site. The keyword in that sentence is the word “approved”. You can have as many versions of a piece of content in the “Draft” state as you want. That will not impact what will be seen on the live site. Only approved versions matter for what is available for viewing. Thus, if you have 10 versions of a page with versions 1-8 in the “Approved” state, version 9 in the “Awaiting Approval” state, and version 10 in “Draft” state, version 8 will be what is viewable on the live site since it is the highest numbered “Approved” version of the page. If your piece of content has multiple language versions associated with it, the latest version in that given language will be what is publishable to the live site.

What does this look like in Sitecore?

On any given Sitecore item, you can see what version you are working on by looking in the top right corner of the item. In the screenshot above, you can see I am viewing version 4 of my Home page. Clicking on the version number lets you see the versions available for editing as seen below:

Clicking on a version in this dropdown will show you the field values on this item in that version.

Creating a new version of an item

To create a new version of an item, all a content author has to do is simply lock and edit an approved version of the item. Content authors will no longer have to go to the version dropdown and manually add a new version of the item to start editing. Workflow makes it possible to only have to lock and edit to get a new version. Locking and editing a version of an item in “Draft” state will not create a new version. It will simply allow you to edit the “Draft” item until you are ready to submit it for approval.

Reverting to a previous version of an item

If you would like to revert an item to a previous version of itself, you will have to lock and edit the version you want to revert to. For example, if you are currently displaying Version 3 of an item on the live site but you want to revert to showing Version 2, you must lock and edit Version 2. This will then create a Version 4 in the “Draft” state with all of Version 2’s content populated in the field values. You will then have to submit Version 4 through the workflow approval process. After getting Version 4 approved, it will be able to be published to the live site and show the reverted values you wanted to see again.

Conclusion

Sitecore recommends that you only have 10 versions max of any item in Sitecore at any given time for performance reasons. In my next blog post in this mini-series, we will go over how to create an automated weekly task that will archive older approved versions of items to keep our content under that 10-version limit.

So far in this mini-series, we have covered how to set up the Simple Workflow and how to automatically place newly created items into it. We now need to create a way to limit which Simple Workflow commands are available to users. In this blog post, we will go over the permissions that need to be applied to Sitecore roles to distinguish which users can submit content for approval and which users can approve the submitted content to complete the workflow. For the sake of simplicity, we will create three separate roles: Author, Approver, and Admin. In your tenant, you may already have different role groups you want to use. That is totally okay. If that describes you, simply view my three custom roles as conceptual. You will need to think of a way to fit your existing groups into each of these three groups.

Role 1: Author

We want users in the Author role to be able to edit content and submit their work for approval. However, we do not want them to be able to approve submitted content. When a user in this role locks and edits an item, they should only see the options below in the ribbon:

Note that the Submit option is the custom Submit command we created within the Simple Workflow that moves items in “Draft” status to “Awaiting Approval” status. Once the user submits their content, we do not want them to see the Approve or the Reject commands we created. Their options should look like below:

In order to get ONLY these options for users in the Author role, we must set the access permissions to the Simple Workflow commands in the Security Editor. Once you are in the Security Editor, click on the Columns option in the ribbon. Ensure that the “Workflow State Delete”, “Workflow State Write”, and “Workflow Command Execute” boxes are checked.

After checking those boxes, ensure you are editing security permissions for the Author role. Then set the permissions to match the screenshot below:

Role 2: Approver

We want users in the Approver role to be able to submit their work for approval and approve submitted content. When a user in this role locks and edits an item, they should see the options below in the ribbon:

Note that users in the Approver role also get access to the Submit and Approve command we created within the Simple Workflow that moves items in “Draft” status to “Approved” status. If a user in this role navigates to an item that has been submitted, they should have access to the Approve and Reject commands like below:

Like before, we will need set the access to the Simple Workflow commands in the Security Editor for the Approver role. Simply update the access permissions as seen below:

Role 3: Admin

The Admin role is not particularly needed to round out our workflow. However, I recommend having some users in some sort of Admin-like role for your content. They should have all the powers an Approver has right out the gate. However, you may want to limit access to various content for the Author and Approver roles. I like to hide technical items that require Sitecore development knowledge from these users and only make them visible to those in the Admin role. With regards to the Simple Workflow, set up the access permissions as seen below:

After setting these permissions, go back to each role and update the access permissions to the appropriate content those users should be able to see.

Workbox

You can also perform the Simple Workflow commands from within the Sitecore Workbox. You can find the Sitecore Workbox in the Sitecore Launchpad. Once you are there, you can see which items are in “Draft” status and which items are in “Awaiting Approval” status. The options that one can perform on an item will match the permissions we set earlier in this blog post. For example, below is a screenshot of what an Approver can see/do in the Sitecore Workbox:

Comments

If you recall from earlier in this mini-series, we set the Default Comment Template and the Default Comment Dialog Height to the values seen below on the Simple Workflow root item:

When a user performs a Simple Workflow command, the user will be presented a comment field that they can use to provide reasonings for rejections or various notes. The pop-up will look like the screenshot below regardless if the user performs the Simple Workflow command in the Content Editor or the Workbox:

The comments that are submitted on an item can be viewed when clicking on the History option on the item.

Conclusion

Have questions about my mini-series thus far? Feel free to leave a comment below, and I will gladly assist you. This mini-series still has much more to cover. Stay tuned for more posts dealing with version control and speeding up the workflow process for those with the power to approve content!

In my previous post in this mini-series, I went over the creation of the Simple Workflow and its states. In this post, we will go over how to automatically place Sitecore items into the Draft state upon creation. We will cover two approaches to implementing this: setting the Draft state in the Standard Values of items or using the rules engine to assign workflow values on item creation. Using the rules engine is my recommended approach, but there are some scenarios where setting the Draft state in the Standard Values of items can be effective. We will also go over how to apply workflow to pre-existing content if workflows are being implemented post go-live.

Route 1: Setting Draft State in the Standard Values

Simply go to the Standard Values item of a template for items you want to be automatically enrolled in the workflow process upon creation. Then update its Workflow accordion fields to place the item into the Simple Workflow.

Very easy, right? There is one major con to this approach that I want to point out. If your Sitecore solution contains multiple tenants for various companies and you want to apply workflow to a template that is used in multiple tenants, you should NOT use this route. Content authors in other tenants will not have configured access to move the content through the workflow. Also, the workflow is specific to a company’s business process. It does not make sense to enforce these workflow rules on another company’s content. If this scenario is one you are in, I highly recommend taking Route 2 over this one.

If your tenant is the only expected tenant in the Sitecore solution or you have a small subset of templates you want to apply workflow to, then Route 1 is certainly effective. Simply add the workflow state information to the Workflow accordion on the Standard Values items of the templates.

Route 2: Using Rules Engine to Enroll Content

The route I recommend following is creating a rule in Sitecore to automatically place a newly created item in your site into the Draft state of the Simple Workflow. With this route, you can specify the conditions that need to be met in order to get enrolled. If you have multiple tenants in your Sitecore solution, you can specify to only apply this custom workflow on items created under certain sites. To implement this rule, read through this excellent blog post written by Amir Setoudeh. After following the steps written in that blog post, I would recommend making the changes below for this Simple Workflow.

public override void Apply(TRuleContext ruleContext)
{
      if (ruleContext.Item == null) return;
      if (!ID.IsID(workflowid)) return;

      using (new SecurityDisabler())
      {
         using (new EditContext(ruleContext.Item))
         {
            var workflow = Factory.GetDatabase("master")?.WorkflowProvider.GetWorkflow(workflowid);
            if (workflow != null)
            {                                               
               ruleContext.Item.Fields["__Workflow"].Value = "{383BA454-6AFA-44BA-8B80-CB0F17C3A196}";
               ruleContext.Item.Fields["__Default Workflow"].Value = "{383BA454-6AFA-44BA-8B80-CB0F17C3A196}";
               ruleContext.Item.Fields["__Workflow State"].Value = "{2FAE5E8D-E153-4F89-BE87-5F367FCAFEE9}";
            }
         }
      }
}

In the linked blog post, workflow.Start(ruleContext.Item) is used to enroll the content item into the workflow. However, once the content item has made it through the approval process one time, it will no longer get back into the workflow once changes are made to it. My code above allows for content to re-enter the Draft state after being approved if more changes need to be made and approved. If you do not need content to re-enter workflow, then stay in line with the linked blog post.

You will also need to specify the rule of when to apply the workflow to an item. For me, I wanted to apply the workflow when a content author inserted items under specific folders. In the screenshot above, if a user inserted an item under the Global item, it would automatically be enrolled in the Simple Workflow in the Draft state.

Applying Workflow to Pre-Existing Content

You may be getting around to implementing Sitecore workflow for your site’s content authors after tons of content have already being created. In either route you went with above, you will still want to place all pre-existing live content in the Approved state. To do this, I wrote up a PowerShell script that will automatically populate the Workflow accordion fields on every piece of content that is under a specific item (including the specific item). This script can take a very long time if there is a lot of pre-existing content. Be prepared. See that script below:

$folderItem = Get-Item -Path "master:<insert path of item>"

Get-ChildItem -Path $folderItem.FullPath -Recurse -WithParent |
        ForEach-Object {
            Write-Host "Moving to Approved State" $_.Name
            $_.Editing.BeginEdit()
            $_.Fields["__Workflow State"].Value = "{0BE6F9DA-8636-4BDA-887A-F0587FFF17EA}"
            $_.Fields["__Default Workflow"].Value = "{383BA454-6AFA-44BA-8B80-CB0F17C3A196}"
            foreach ($version in $_.Versions.GetVersions($true))
            {
                if($version.Locking.IsLocked())
                {
                    $version.Editing.BeginEdit()
                    $version.Locking.Unlock()
                    $version.Editing.EndEdit()
                }
            }
            $_.Editing.EndEdit()
        }

Now that we have covered what a workflow is in Sitecore, let’s jump into configuring workflow states in a custom workflow. Again, the number of workflow states you need is entirely up to the requirements of your business process for getting content approved. This post will walk through the creation of a simple workflow. This workflow will contain three states: Draft, Awaiting Approval, and Approved. This means that at any one time, a piece of content in Sitecore will ALWAYS be in one of these three states (if workflow is applied to that item).

Configuring the Simple Workflow

In the Content Editor, navigate to /System/Workflows. Right-click the root Workflows item and insert a Workflow.

Set the Default Comment Template and the Default Comment Dialog Height to the values used in the screenshot above. Those values will come into play in a separate blog post later in this mini-series. The Initial State field will be set to be the first state a content item will start at when progressing through this workflow. Be sure to set this value to Draft state after we create them in the next subsection.

Configuring the Three Workflow States

On your newly created Simple Workflow item, right-click and insert the three states and name them: Draft, Awaiting Approval, and Approved.

On the final Approved state item, be sure to check the Final checkbox field. This indicates to Sitecore that an item in the Approved state is allowed to be published to the CD server.

Progressing Content through the Workflow States

Now that we have the three states configured, we need to configure commands content authors can take to push content from one state to the next. To create commands, simply right-click the workflow state and insert a command. For the Draft State, we will create two commands: the Submit command and the Submit and Approve command.

On each command item, we will need to configure what state to move the content to after performing the command. The Submit command will move the content to the Awaiting Approval state. The Submit and Approve command will move the content to the Approved state. In a later blog post, we will configure what users can perform which commands. Some will only be able to submit content for approval while others will be able to directly get the content to the final approved state.

The main difference between the two commands is the state in which the content moves to after performing the command. Another difference I made here is checking the Suppress Comment field on the Submit and Approve command but not on the Submit command. This will be explored in a later blog post.

Now that we have created the commands that can get a piece of content out of the Draft state, we will now create two commands for content that is in the Awaiting Approval state. We will allow for two commands to be performed here: Approve and Reject. These commands will be set to be visible to only content authors with the power to approve and reject content in a later blog post. If the Approve command is performed, we will move the content to the Approved State. If the Reject command is performed, we will move the content back to the Draft state for a content author to make further necessary changes before approval.

Conclusion

And that’s a wrap! That’s all you need to do to configure the workflow items in Sitecore. Stay tuned for future blog posts that dive into what this workflow looks like in action.