Custom fields per customer (who has customers)

[skalla]

Hi there,

we are currently looking into migrating from ACT 2000 to sugarcrm. The migration of existing databases is not our main concern. But a real show-stopper feature is the following:

We currently have many (>100) databases in ACT2000 each for a different customer of us for which we do telephone support. Each database (and thus customer) has its own set of fields in the db which our call-center agents must fill during a support session.

The question is how do I map this scenario to sugarcrm?

Thanks in advance
Skalla

[GameboyRMH]

I started work on a module to do something similar, but importing data into it could be tough...

The module basically contains a set of fields like those of a database record, and can be related to an Account.

The idea is that when I'm finished, I can view an account and see the related records in a subpanel, and then edit or delete them (similar to Notes in the History subpanel).

The problems are that each record must be manually related to an account, and each record will have it's own row in one big messy table in the sugarCRM database, sortable only by the id of which account it's related to but it should do the job. I'll probably have to edit some PHPs to get the subpanel to work properly as well.

You should be able to do this in Studio, at least if you're running a version that allows new module relationships to be set in Studio (any v5 release IIRC)

[Angel]

You are going to have multiple problems no matter how you slice this.

First and foremost is the issue of whether or not you want all those individual ACT! databases to exist within a single SugarCRM database. If that is not an option, meaning, you *must* keep them separate for business or other reasons, then you will need to create separate installs of Sugar for each database as Sugar does not support the use of multiple databases. An alternate method would be to use differing config.php files, one for each database, but that could present other problems.

Secondly is the issue of the field layouts or views. If you need them to be different for each database, the much easier approach would be to have a separate install of Sugar for each database.

Of course, if you do not need to keep them separate, you could create the necessary fields in one Sugar database and then do your import.

[skalla]

First thanks to you both!

@GameboyRMH
We are evaluating version 5. I took a look at the studio an it seems like I can customize the fields, but I didn't see any way to customize them "per our customer".

@Angel
I can only have one sugarcrm installation with one mysql db. There are non-techies who must also be able to set up new customers (our customers, who have the real customers we speak with) with custom fields.

Import of existing data is not planned right now, we would try to use it only for new customers first.

I'm a techie, not a crm guy. I thought maybe I could use "projects" or "campaigns" for this. But maybe thats just not possible?

[GameboyRMH]

Do you need individualized fields for each customer or a different set of fields depending on customer type?

[skalla]

Individualized fields for each customer. Just to be clear: Customer here is a company which has many customers, for these latter customers all fields are the same.

[skalla]

Anyone else have ideas?

[andopes]

Hi, skalla.

The steps you could figure out:

1. Create a custom field for each customer fields;
2. Create a metadata script, perhaps modules/Accounts/metadata/customers_defs.php
Inside this metadata you would related the customer id (Account id of your customer) with its custom fields.
3. Create a new script like modules/Accounts/RenderView.php, wich would render the EditView and DetailView of Accounts based on custom fields for a given customer (Account id). This script will create a new box called with all custom fields for the selected Account, including all fields name for sending by POST to AccountFormBase.php.
4. Inside the EditView.php and DetailView.php you just include this new script before the xtpl->parse() and assign some XTPL entry to the html returned from the new script;
5. Inside EditView.html and DetailView.html you just show this new XTPL entry.

We have done it for a client with the same needs and it works properly. System already in production.

Cheers.

--
André Lopes
Lâmpada Global Services
Rua Bela Cintra, 299 conjunto. 51
São Paulo, SP 01415-000
tel1. 55 11 3237-3110
cel. 55 11 7636-5859
e-mail: info@lampadacrm.com.br

[skalla]

Wow, first many thanks to you andopes!

It's good to hear that you have done something similar and that it's possible in principle! Seems like I have to have to dive into this much more than I thought.

I don't understand your first point, where/how would I do this?
The other points seem to be doable if I dive into the code. Is it possible that you send me your scripts so I can take them as an example? But I'm not disappointed if that's not possible, you already helped alot!

Thanks again
Skalla