---
title: Workflows
---
= Workflows

Workflows are all-encompassing NixOS modules for dictating how you interact with your computer/device/whatever.
Basically, this is where certain things are set such as your GNOME desktop environment settings, your dolled up standalone window manager setup, or an oddball audio-only desktop interface.
They are located in `./nixos/modules/workflows` at the project root.

Workflows are defined under the namespace `workflows` where each workflow module is set to be declared and to be enabled at `workflows.workflows.<name>.enable`.
For example, here's how I would enable my imaginary GNOME desktop workflow.

[source, nix]
----
{ config, lib, pkgs, ... }:

{
  workflows.workflows.a-happy-gnome.enable = true;
}
----

Take note you cannot enable more than two workflows at any given time.

[source, nix]
----
{ config, lib, pkgs, ... }:

{
  # This would cause an assertion error.
  workflows.workflows = {
    a-happy-gnome.enable = true;
    knome.enable = true;
  };
}
----

You can get around this by setting `workflows.disableLimit` to `true`.
However, this shouldn't be taken lightly as workflow modules are very vast in scope and are expected to set system settings that can affect your hardware including...

* Enabling (and/or disabling) system services such as the preferred network manager.
* Modifying the list of installed applications.
* Setting up programs with custom configurations which could cause conflicts with the defaults (upstream or from nixpkgs) or with another workflow module.

[chat, foodogsquared]
====
By organizing the workflow modules this way, you can easily create your desktop rices without overlapping system settings.
Bless the Nix module system!
====

[chat, foodogsquared, state=cheeky]
====
Whether those rices are worth posting to Unix ricing communities is up to you though.
====

[chat, Ezran, state=disappointed, role=reversed]
====
Whippersnappers with your "riced"-up systems...
====




== Designing a workflow module

There are a few guidelines to designing a workflow module which is already laid out in its respective README but as a reminder, let's list it here.

* All workflow modules should be under `workflows.workflows.<name>` namespace with an `enable` option.

* No usage of the private modules.
It is a public module, after all so it'll make things messier.
While we can conditionally set the configuration, it is pretty useless since we have the xref:../03-disko/index.adoc[host-specific module structure].

* No locale-related settings.
Each user may have its own set of preferred locales and their setup so it is pretty much prohibited from setting any.
The only related parts a workflow module can set is their preferred input method engine (IME) of choice.
The rest of the locale settings is best configured from the host or its individual users.