Be very careful when looking at this kind of data. There's considerable variation by hardware platform and even software revision that influences whether TCP information is collected and whether that data is actually collected consistently.
When it does work, the TCP information collected by Netflow is a logical AND of the TCP flags seen during that flow interval. Keep in mind that a TCP flow lasting, say, 30 minutes might actually generate between 5-6 and potentially dozens of records as aging timers hit, caches overrun or, indeed, FIN packets are seen (in the case of TCP). As such, unless something is assembling these flow records into some kind of a cohesive whole what you're actually seeing is a bunch of (hopefully) sequential chunks.
If TCP flags are being correctly flagged then you might see an interval from, say, the first 30 seconds of the flow where both SYN and ACK were seen. This would create a value of 010010 (decimal 18). If retransmissions were happening later in the session - say 10 minutes in - then a later record might include 000100 (decimal 4) reflecting that the RST flag was observed. Toward the end of the overall session you might see a final record that included 000001, indicating a FIN flag.
Similarly, if an entire flow occurs within the bounds of a single record then the entries for SYN, ACK, RST and FIN might all be seen (010111). During an uneventful section of the flow there also might be no flags set at all.
FYI - the TCP flags (from most to least significant bits) are URG,ACK,PSH,RST,SYN,FIN.