diff --git a/source/concepts/what.rst b/source/concepts/what.rst
index 18c776c13bc7ec10ba7103d0be43f80226ded29c..e41136a71a9b13ca239c6edc218903e98c4df050 100644
--- a/source/concepts/what.rst
+++ b/source/concepts/what.rst
@@ -54,27 +54,51 @@ research archive
 How do we decide what to integrate?
 -----------------------------------
 
-Some workflows need to be deeply integrated with contact management. A good
-example for this is the recruitment, which is centered around communication
-with the subject. These workflows are integrated in Castellum.
+An underlying question when implementing a new feature for Castellum is about 
+the intended level of software integration. Some workflows need to be deeply 
+integrated with contact management. Other workflows should be kept completely 
+separated. Furthermore, we also want to highlight the possibility to completely 
+reject a feature.
 
-Any other workflows should be kept completely separated. For example, research
-data should not be stored inside Castellum. Note that there is no need for a
-streamlined, integrated UI because research data is (or at least could be)
-handled by completely different staff than contact data and recruitment.
+A good example for a deep integration in Castellum is recruitment, which is 
+centered around communication with subjects.
+
+An example to show the opposite is research data. It should not be stored 
+inside Castellum. Note that there is no need for a streamlined, integrated UI 
+because research data is (or at least could be) handled by completely different 
+staff than contact data and recruitment.
 
 .. note::
    There are only two notable exceptions to this rule: Study participations and
    search attributes both contain traces of research data, but are required for
    the recruitment process.
 
-Workflows will also be kept out of Castellum if there are well established
-processes that do not need to be replaced. Examples might include calendars or
-room management.
-
-The integration with external processes is usually manual. For example, a
-pseudonym generated by Castellum would usually be entered into a MRI device by
-hand.
-
-However, if sufficiently established protocols are available, we try to support
-them. For example, authentication can be handled via a central LDAP service.
+We often found it difficult to decide on levels of integration. Therefore, we 
+want to provide some guidelines that should be considered before adding a new 
+feature to Castellum:
+
+* Can the feature be decoupled from communication with subjects? We found this 
+  to be a good starting point to remind us on the main focus of a tool for 
+  recruitment.
+    
+* Would the new feature introduce different staff members (user groups) 
+  who would use Castellum only for this reason? For example, we decided against 
+  integrating a *public relations view* on current studies as it would have 
+  introduced staff members who actually are not allowed to access subject data.
+   
+* Are there well established processes or tools that do not need to be 
+  replaced? Examples might include calendars or room management.
+
+* Are there established protocols to interface with the existing services 
+  instead of reimplementing it? For example, Castellum supports authentication 
+  via a central LDAP service.
+
+* Is it acceptable for users to integrate with external processes manually? For 
+  example, a pseudonym generated by Castellum would usually be entered into a 
+  MRI device by hand.
+
+* Is the feature preventing us from addressing the various needs of different
+  research institutes?
+
+Rather than applying these questions as strict rules we try to balance them
+within the process of reaching a decision.