Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 354 subscribers
  • Views 715 views
  • Users 0 members are here
Forum Actions
Related

application-wide custom dynamic badge

Francesca Shiekh

We have a select list of customers who are Fields Medalists, Nobel Prize winners etc. as well as some long time customers who get a VIP status. 

We track these people in a custom module where we have Name, Email Addresses (which may or may not be related to Contacts/Leads etc), VIP level and a VIP Description with "special handling" instructions.

I have APIs to get VIP Level (1,2,3) and VIP Description based on first/last name and/or email address.

I would like to achieve the following (but will listen to alternatives):

  • Every detail and list view (regardless of module: e.g. Contacts, Leads, Opportunities, Cases, Quotes etc...) that has an email address (primary or otherwise) or name that matches one in our VIP module related to it, should have a "VIP Badge" next to the record's name to indicate the level of VIP
  • Hovering over the "VIP badge" shows a popup with the VIP Description returned by the API calls.
  • Regular users do not have access to the VIP Module, the APIs make sure they only see the two fields they have access to: Level and Description.

Note that the VIP Module does not directly relate to records in Contacts, Leads etc.. hence the API lookups.

I looked at the cookbook for highlight field but it doesn't quite fit my needs...

I considered a Dashlet but we don't want users to be able to ignore it (like closing the side pane)

I am thinking a modification to the "name" field type that would check fields and relationships in the module and call the APIs to find any matching records in the VIP Module, and add a conditional dynamic badge to the .hbs ...but I'm worried I am going to end up putting a ton of overhead on every possible view that way...

Any thoughts on the best way to tackle something like this?

Brainstorms welcome Grinning

Thanks,

FrancescaS

Parents
  • 0

    Hi ,

    My initial thoughts are that it sounds like this information is relatively stable on a day-to-day basis. If that's accurate, I think the bulk of your work could be handled by a scheduler that runs nightly checking the email address & name of your VIP records against any desired modules. When matches are found, it would feed the current level and description into custom fields on each module to avoid having to expose data directly from the VIP module. Then, the visibility of the badge would be made dependent on the custom fields in that module's record being populated. A few scenarios I recommend considering with this approach are:

    1. You would likely need to account for someone no longer being a VIP to ensure those values get cleared from any related modules.
    2. If don't want to wait for nighttime processing, you could compliment the scheduler with hooks created to do a real-time check for scenarios such as:
      1. When an email address/name is added or changed on a target module to see if a match exists in the VIP module
      2. When a new VIP record is created, scan against the other modules (depending on performance of this, you could instead create a job_queue entry to perform this check on the next cron run)

    Co-Founder | SugarCRM's 2024 Global Outfitters Partner of the Year

Reply
  • 0

    Hi ,

    My initial thoughts are that it sounds like this information is relatively stable on a day-to-day basis. If that's accurate, I think the bulk of your work could be handled by a scheduler that runs nightly checking the email address & name of your VIP records against any desired modules. When matches are found, it would feed the current level and description into custom fields on each module to avoid having to expose data directly from the VIP module. Then, the visibility of the badge would be made dependent on the custom fields in that module's record being populated. A few scenarios I recommend considering with this approach are:

    1. You would likely need to account for someone no longer being a VIP to ensure those values get cleared from any related modules.
    2. If don't want to wait for nighttime processing, you could compliment the scheduler with hooks created to do a real-time check for scenarios such as:
      1. When an email address/name is added or changed on a target module to see if a match exists in the VIP module
      2. When a new VIP record is created, scan against the other modules (depending on performance of this, you could instead create a job_queue entry to perform this check on the next cron run)

    Co-Founder | SugarCRM's 2024 Global Outfitters Partner of the Year

Children