Fields visibility based on a dropdown number

I'd create a new module called Vehicles and relate it to Accounts. In creating the new Module I'd look at basing it on the Calls or Meetings Module if possible as the information you are largely setting up is date based (and possibly even recurring). You won't need to touch code, logic hooks etc just Module Builder/Loader and Studio. You can do this even if on Sugar Cloud. The benefits of a new module related to Accounts will be apparent very quickly rather than trying to add fields into the Accounts Module. 

Note only use the Module Builder to initiate the new Module. Do all the customisation, new fields etc in Studio. There is a SugarCRM best practice article on this. I didn't realise it once and had to recreate a module from scratch.

A new module makes totally sense, thank you Greg.

Hi Andrea,

SugarCRM is undoubtedly the best CRM on the market (I call it "The poor person's Salesforce.com").  You can very easily adapt the SugarCRM modules to match your business model.

You could create all of the fields in the Accounts module and set each of them as "visible if" based on the number in the number of cars field.

If I knew more about the business process, I might suggest creating a new module or "hijacking" an existing module for "cars"...

Well said Greg Barrass. Depending on the circumstances, I'd also recommend trying a Basic module if Andrea wanted to define all the fields and have more of a blank canvas, but this might be a personal preference.

Here is the article mentioned above too: https://support.sugarcrm.com/Knowledge_Base/Studio_and_Module_Builder/Best_Practices_When_Building_Custom_Modules/ 

Edit: these two articles may help as well in this circumstance:

• Sugar Logic Walkthrough - Next Call Due Date
• Capturing Records' Activity Counts Using Calculated Fields 

Dear Andrea,
If you would like to get more from CRM to improve customer service and sales of related services, I'd suggest adding modules Vehicles, as Greg recommended, and "Vehicles Checks" (related to Vehicles and Accounts).

In this case, you'll get more flexibility:
- to see the full history of checks for a particular car, not only the previous one
- to use the history of checks for prediction (e.g., finding out customers who require checks frequently than others).
- to extend the set of check's types (check the battery, the cooling liquid, ...)
- to configuring workflows on a particular check
- ...

I hope it helps you

I agree with Mykola Bulava, because and Account can have many vehicles and vehicles many checkups using two additional very simple modules is best: one for the vehicles related to Accounts, and one for the checkups related to the vehicles.

Careful with circular relationships though.

Account-> Vehicle -> Checkups is fine and using the relationships you can find all the Checkups for a given Account, but if you also relate Checkups <-> Accounts you need to make sure that when a Checkup is related to an Account the Vehicle is also related to that same Account and vice versa, if a vehicle belongs to an Account all the Checkups for that vehicle should belong to that Account.

FrancescaS

Thank you Alex, very helpful.