Partendo dalla definizione di base di workflow, visto come un modello di processi umani o di sistema definito da un insieme di attività, poniamo l'attenzione su come il flusso di operazioni definito da questi tipi di modelli logici venga instradato da particolari tipologie di condizioni presenti all'interno di una o più attività figlie del workflow stesso.
Il concetto di condizione è parte naturale di tutti i processi di business che normalmente vengono utilizzati per risolvere le più comuni problematiche, così come quello di regola.

Per chiarezza iniziamo definendo una condizione come un costrutto booleano che deve dare come risultato vero o falso.

Procedendo per esempi (ed utilizzando un linguaggio di alto livello), una condizione può essere benissimo utilizzata per controllare se l'anno corrente è un anno bisestile:

((anno % 4 == 0 && anno % 100 != 0) || anno % 400 == 0)

Di seguito invece una regola come un oggetto logico strutturato da un insieme di condizioni legate tra loro con relative una o più azioni da eseguire in base al risultato della valutazione sulle condizioni di partenza.

IF ((anno % 4 == 0 && anno % 100 != 0) || anno % 400 == 0)
THEN  print("Anno bisestile !")
ELSE print("Anno normale !")

Proprio grazie a queste peculiarità, condizioni e regole rappresentano la base decisionale di un workflow, in quanto permettono appunto di modificare il percorso d'esecuzione del flusso di operazioni in base a valori costanti, informazioni di input o dati modificati da particolari eventi scatenati in precedenza.
Il motore di Windows Workflow Foundation offre un supporto completo agli sviluppatori sia per la costruzione di condizioni che di regole, oggetti che potranno poi essere utilizzati all'interno di una o più attività condizionali poste all'interno del proprio flusso. Tale supporto, in termini pratici, si traduce in:

• un insieme di attività condizionali che permettono di ramificare il percorso del proprio workflow;
• editor di condizioni;
• editor di regole ed azioni;
• serializzazione XML di singole regole o gruppi di regole (denominati RuleSet);
• strutture per l'utilizzo di condizioni e regole al di fuori di un workflow.

In particolare, possiamo citare quattro attività (dette appunto condizionali) che necessitano del risultato della valutazione di una condizione per procedere con la propria esecuzione e quella del workflow che le ospita.

La prima è la IfElseActivity, attività che contiene uno o più rami (di tipo IfElseBranchActivity) che vengono percorsi se la valutazione della proprietà Condition ritorna il valore booleano di verità (true).
La seconda è la WhileActivity, attività che esegue una singola attività figlia in maniera iterativa fin quando la condizione di entrata del ciclo, rappresentata anche in questo caso dalla proprietà Condition, non ritorna un falso (proprio come se si stesse utilizzando un ciclo while nei più comuni linguaggi di programmazione).
La terza è la ReplicatorActivity, attività che esegue istanze multiple di una singola attività figlia fin quando la condizione definita all'interno della proprietà UntilCondition non ritorni una verità. Il comportamento di tale attività è molto simile a quella offerto dalla WhileActivity.

La quarta ed ultima, facente parte del gruppo di attività condizionali, è la ConditionedActivityGroup, attività che permette l'esecuzione ripetitiva di una o più attività figlie, che a loro volta hanno una singola condizione da rispettare (contenuta all'interno della proprietà WhenCondition) per potere essere eseguite.

Tutte le proprietà delle quattro attività condizionali che contengono la definizione vera e propria della condizione (Condition, UntilCondition e WhenCondition), sono rappresentate dal tipo ActivityCondition, classe astratta che rappresenta una qualsiasi espressione condizionale in grado di ritornare una valore booleano. Tale classe astratta, vede due implementazioni concrete:

• CodeCondition;
• RuleConditionReference.

Queste classi rappresentano due ben distinte tipologie di condizioni, che vedremo ora nel dettaglio.