Core features Address Data
Our concept how to treat address data system-wide
Service:
In order to be able to process addresses as data objects, we install the popular TYPO3 extension "tt_address " and configure a data model that covers your current applications, but is also equipped for future scenarios.
Functionality:
The address management is the foundation for three basic usage scenarios:
- Collection of personal data using forms on the website
- Display of personal data on the website
- Presentation of organisation-related data on the website
The scenarios are based on a uniform model, so that a data set can change from one scenario to another, e.g. if a newsletter recipient becomes a member of (1st scenario) and wants to appear in the public directory of members (2nd scenario).
Our address management uses the e-mail address as the primary identification feature. This has the advantage that data records can be created everywhere in TYPO3 where data is collected via forms that require at least an e-mail address, e.g. even when subscribing to a newsletter without any further information except an e-mail address. This has the disadvantage that the rare case in which several people use one e-mail address cannot be covered: So with familie.lafontaine@aol.com or info@company.com only the first registered person will be able to use the website.
These data records are first stored in the data tree in a central location. From there, they can be synchronized with internal contact management programs (CRM systems), which we recommend for larger data volumes (we will gladly advise you on suitable systems). The address model only provides for data that can potentially be used on the website and does not fall into the category of data requiring special protection. Information such as party, religious or trade union affiliation, health or banking data should always be stored directly from the website to an external CRM system.
Address records can be categorized as usual in TYPO3. Thus, when using the topic feature, people can be assigned to (super- or sub)topics. It is also possible to use a separate category tree as a classification system, e.g. for persons, in order to be able to filter lists of persons according to personal categories in the list feature (free field entries, such as "role" or "department" are not suitable for filtering).
Planning:
The data model provides for mail code and browser code. In the future, newsletter or mailing recipients who come to the website via a link in the newsletter or mailing can be re-identified. This allows the offer to be more closely aligned to the situation of the contact. If the person uses the same browser as he or she did last time, he or she can be considered as registered and functions can be offered directly that would otherwise require a login with email and password.
Documentation:
Which record type contains which data by default? How is the data structured in the interface? What are the assumptions regarding publication, approval and possible usage scenarios?
This feature is based on the extension(s):
tt_address, wwt3_address
This feature was already used in the version(s):
8, 9, 10, 11
Use cases
Scenario 2: Personal pages can be based on data sets and thus make this data filterable - e.g. for parliamentary groups so that members can be found not only by topic, but also by constituency or election period - or, as here at ifW Kiel, differentiated by researchers and fellows.
Scenario 3: Institutional members of an association are displayed on a map, such as the vocational training centres on the website of their umbrella organisation BAG BBW.