Social Groups in XMLPortal, through BrightSide Contacts.

Contact databases are easily made unmanageable. They tend to grow in an unordered manner and carry those defects inherent to non categorized huge databases. Users might be able to see the whole database or may end up creating contact duplicates. As long as contacts database is attached to web users database, privacy isn't satisfied. Anyone seeing contacts sees users, maybe even permissions, roles and the like. But how to avoid it? Giving yourself each customer, provider, collaborator and so on, its permissions? Certainly not.

Here is where Social Groups comes in help. Build upon BrightSide Contacts, Social Groups define the way a contact has to be categorized, to those has to be related and which permissions is allowed. Social Groups make a clear vision of Contacts database.

 In short, a Social Group specifies some fixed criteria, as to find those members that fit in the group, and some variable criteria, as to make easier for related members to find contacts.

Criteria builds on existing contact properties, like tags, connectors, addresses, configured fields. You can syndicate a contact into a Social Group by setting those attributes or by simply checking its Social Group Syndication. This second option is what makes BrightSide Contacts a real set-isolated / related system. By setting groups like Administration, Customer, Employee and others, and relating those groups you could allow an Administration contact to set a Customer contact its permissions by checking its Social Group Syndication. Easy, secure and clear.