The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
An Architecture Question - What to do when there is no natural Account structure
Posted: 10 Jul 08 9:03 PM
|
We have a client that will be capturing contact data for those members of the public who will be their customers.
For these contacts, there is no obvious 'Account' structure and I am wondering what other people do in such situations? There are three obvious alternatives and I do not know how to choose the best - what do others think?
1) Create an account for every contact
2) Create a single account and group all contacts underneath it
3) Create an arbitrary group of accounts (eg, for all surnames beginning with A, B, C etc etc, or based on some other simple criteria)
I do not like the idea of (1) - just seems like a good way of creating way too much redundant data.
(2) is clearly the simplest, but contact numbers are potentially in the millions and I am a little worried about that.
I am looking forward to any comments & ideas.
Thanks
Phil
|
|
|
| |
| |
|
Re: An Architecture Question - What to do when there is no natural Account structure
Posted: 15 Jul 08 1:07 AM
|
Option 2 - just don't let someone pull up the contacts tab under the account, and disaster is averted.
I used option 1 at my last job and HATED it. I totally regret that decision - lots of confusion in the long run, and customer service probably hates me for having to look up customer information on two screens rather than one. |
|
|
| |
| |
|
Re: An Architecture Question - What to do when there is no natural Account structure
Posted: 15 Jul 08 6:19 PM
|
I haven't started the dev work yet, but I'm thinking like this:
- Create a single account, owned by everyone. Security is not an issue at this point and because of the nature of the business I do not think it ever will be, but if necessary I could implement something at contact level in future. This would not be a quick job.
- Modify the Account/Contact creation process to create contacts associated with this account (the user will not know that this is happening). Account maintenance available to admin only.
- Hide the account entity as much as possible - forms, menu items, toolbars, the works
- Remove contact searches that are using non-indexed fields. In fact, create a custom search screen for contacts.
- When the db gets large, ongoing db index tuning to keep performance acceptable.
I am quite sure that there will be many other implications of going down this road - I will know more in a few weeks' time.
Phil |
|
|
| |
| |
| |
|
Re: An Architecture Question - What to do when there is no natural Account structure
Posted: 18 Jul 08 9:07 AM
|
I've seen this situation a number of times. The most common solution is to use your option #1 (one account per contact). 'Always hated that approach. We used option two for an employment/consulting company, and although we had some problems, it worked out well. Option #3 may also be a good idea, but I've never tried it. One of the replies above warned about the Contact Tab when using Option #2. Yep, been there. We built a replacement tab containing 26 sub tabs, one for each letter of the alphabet. That was a few years ago back in Slx version 5, but it worked just fine. We also kept the normal Account structure as that company also used Slx for normal business contact situations (suppliers, vendors, customers, etc.).
Additional question: Will your client be selling to these "contacts" on a cash basis? If so, you may wish to bypass the normal Slx Opportunity feature, and build a sort of a "cash register" sub-application.
|
|
|
|