Behaviors are born of the idea that consolidating control of data flow to the objects most relevant to its collection and delivery creates a more streamlined and effective Grooper experience.
If the Content Type controls all the relevant information about how documents are organized and what is to be collected from them, it is logical that controlling how those documents come into Grooper, and how they get out, should also be defined by the same object. It is also a much cleaner experience to no longer have multiple steps in a Batch Process to cover the types of Export activities, but instead a single Export activity that leverages the Behaviors of the Content Type, Behaviors defined on the Export activity, or both.
If you take CMIS Connections, for example, Grooper previously created an unnecessary amount of objects to get to the CMIS Content Type. The mappings for importing and exporting were also set here, which made for more places which a person need to go to configure the flow of data into and out of Grooper. It also created a bottle neck of control because if you wanted to have disparate Content Types use a similar CMIS connection, but the import/export mappings inherently needed to be different, you would have had to create a separate CMIS Content Type. Now, one CMIS Repository object can exist, and the import/export mechanisms are controlled via Behaviors (again, defined on Content Types or Export activities).
