diff --git a/CHANGELOG.md b/CHANGELOG.md
index b67fd9ac459..82e74095100 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,5 @@
+- Documented uptodate action in Common Workflows Guide as
+  background information
 - Documented handling of pub directory of the web server in the
   context of proxy (bsc#1238827)
 - Added instructions for Server and Proxy installation on SUSE Linux
diff --git a/modules/common-workflows/pages/workflow-clients-update-rec-actions.adoc b/modules/common-workflows/pages/workflow-clients-update-rec-actions.adoc
index 8c3c7428a5a..92c244133c3 100644
--- a/modules/common-workflows/pages/workflow-clients-update-rec-actions.adoc
+++ b/modules/common-workflows/pages/workflow-clients-update-rec-actions.adoc
@@ -75,6 +75,80 @@ A third step is optional but highly recommended to finalize the update process.
 . Click btn:[Create Schedule] to save the action.
 
 
+
+[[cw-update-background]]
+== Background Information on [literal]``uptodate`` State
+
+
+. The [systemitem]``uptodate`` state applies critical patches to the update components.
+
++
+
+--
+
+..  On {suse}-based systems, the state executes the command:
+
++
+
+[source,shell]
+----
+zypper --non-interactive patch --updatestack-only
+----
+
++
+
+And then, the state also updates {salt}.
+
+.. On all the other systems, not based on {suse}, the state only updates {salt}.
+
+--
+
+. The state runs the package manager, such as [command]``dnf``, [command]``yum``, [command]``apt``, or [command]``zypper`` based on what is available on the client OS to update the rest of the packages.
+
++
+
+--
+
+.. Listing all of the remaining packages that can be upgraded.
+
+.. Upgrading the packages to their latest available version by using the client's package manager.
+ The version depends on the synchronized repositories in {productname}.
+ This is different depending on the operating system of the client:
+
+... For Debian-based clients, such as Debian or Ubuntu, the action executes [command]``apt dist-upgrade -q -y $PACKAGES``.
+... For RPM-based clients that are not SUSE, such as Red Hat Enterprise Linux or SUSE Liberty Linux, the action executes [command]``yum --quiet -y update $PACKAGES`` or [command]``dnf --quiet -y upgrade $PACKAGES`` (depending on the package manager the client is using).
+... For non-transactional SUSE clients, such as SUSE Linux Enterprise 15, the action executes [command]``zypper --non-interactive --auto-agree-with-licenses update $PACKAGES``.
+... For transactional SUSE clients, the action executes the same in a transactional shell.
+
+--
+
++
+
+// . version 4.3" if SUMULIMA detects that reboot is necessary, for 4.3.x, it will automatically reboot that client.
+
++
+
+// 5.0 and later
+
+. Reboot strategy: reboot and rebootifneeded action exist.
+  Users have the option to select and enable a reboot action.
+
+The following text is related to rebootifneeded.
+
+Reboot detection is, again, specific to the client OS. I'm not sure if this is documented somewhere, but IMHO we should. I think this should have its own documentation page, but I'll leave it up to you.
+
+For Debian/Ubuntu, we could just link to [3].
+
+For non-transactional SUSE clients, we check if any of the patches require reboot by using zypper -x list-patches, and reboot if so.
+
+For transactional SUSE clients, we check if there's a pending transaction, and reboot if so.
+
+For the Red Hat-based clients, we use dnf -q needs-restarting -r or needs-restarting -r.
+
+Customers can see the reboot_info.py module for more information [4].
+
+
+
 == Related Topics
 
 * For more information about recurring actions, see xref:administration:actions.adoc#recurring_actions[Recurring Actions].