Entering the Opportunity Role on the Lead

Hey John Boyes ,

What's the business reason behind your request? Reporting? Tracking changes? Workflows? All of them?

I ask because over the years I found the relationship attributes in Sugar ineffective for several reasons, including the fact that it is not easy to get that information back out of the system (reporting) or even act on it (workflows etc) and because you can only change/add relationship attributes AFTER the relationship has been created as a second step/save for the user.

If you need to store more information on the relationship between two objects (whatever they are), I would recommend creating a module and two relationships for that. Then, to reduce users' burden, you could help them populate the relationship with the correct information with custom functionality (UI, backend and/or a combination). This approach would allow you reporting, workflow capability and changelog.

For example, to track employment history between Accounts and Contacts, that's normally architected in Sugar through a joining module and 2 1-m relationships. And you could populate a record on this new module, every time a person changes account, together with start-end dates, title etc.

Perhaps something similar might suit you best?

Cheers

Hey John Boyes ,

What's the business reason behind your request? Reporting? Tracking changes? Workflows? All of them?

I ask because over the years I found the relationship attributes in Sugar ineffective for several reasons, including the fact that it is not easy to get that information back out of the system (reporting) or even act on it (workflows etc) and because you can only change/add relationship attributes AFTER the relationship has been created as a second step/save for the user.

If you need to store more information on the relationship between two objects (whatever they are), I would recommend creating a module and two relationships for that. Then, to reduce users' burden, you could help them populate the relationship with the correct information with custom functionality (UI, backend and/or a combination). This approach would allow you reporting, workflow capability and changelog.

For example, to track employment history between Accounts and Contacts, that's normally architected in Sugar through a joining module and 2 1-m relationships. And you could populate a record on this new module, every time a person changes account, together with start-end dates, title etc.

Perhaps something similar might suit you best?

Cheers