Skip to main content

I do not know when or understand why this change was made. Best guess someone was able to find was 5 months ago.

 

Prior to this change in order to make records on a Low Volume object editable on a 360 you had to add the GSID of that Low Volume Object to a report. This gave the popup edit icon that allowed you to have end users edit records.

 

Now, after some change, probably horizon change, the edit icon is always there. We have no control on if records should be edited or not.

 

In this sreenshot you can see no GSID

 

In this screenshot you can see the edit icons are there.

 

 

Do I understand why this was probably changed? Yes, obviously it makes reports look ugly/extra effort just to add the GSID to make something editable.

 

However, by you guys no longer making the GSID a requirement and allowing every Low Volume Object report to have the edit buttons you have removed capabilities we had before this change. We as admins no longer have the ability to remove the end users ability to editing Low Volume Objects on the 360.

 

Just a few different use cases where this starts to become a problem.

  • What if that low volume object is meant only for display purposes unless tied to a CTA, where we are able to control the layout of the object and what can be edited?
  • What if you are forced to use a Low Volume object because you need to add a lookup to a GS Standard/system low volume object. Such as a junction object that looks up to CTA and Activity Timeline to bring this data together. This object is purely for display purposes only. But, now the end user will be able to edit fields. Losing changes they’ve made or worse having dupe records created.
  • In our specific use case we have a Low Volume object that looks up to the SP object. On this object we store extra information and track changes, was prior to API. That information we display to the End User. Now, they have the potential to mess things up/change data that should not be changeable because they can edit these records.

 

 

Please change back or give us the ability to flip a switch on the 360 section that says it should be editable or not.

I agree with this and think it should be converted to a bug for resolution.

 

cc: @pgeorge 

Hi @Wayne 

As mentioned, we had multiple feedbacks about how adding the GSID field makes the report clunky with a detail that does not add value. To address this was why the GSID check was removed.

But the control to allow editing a record from the report can still be possible through 2 settings.

In the Report Global Settings the setting to allow Add/Edit records is available. This would be applicable for all reports.

 

Once this is enabled, every individual report can be set to allow Add/Edit from the individual report settings

 

The documentations for the same are being improved and I will share the link once the work is complete.

 

Hope this helps. Do let me know if you require any further clarity.

 

Thank you

Preethi

@pgeorge - This does help, thank you very much!!

Are we able to use permissions to control who can/cannot add records? Or does it have to be all or nothing at the report level, necessitating duplicate reports/access controls via reporting to determine who can add records or not?

Hi @bradley 

The Data permissions will not control who can add records to an Object. They are currently view and edit.

Hence these permissions will not be duplicated or conflicted with the permissions set at report level.

Reply


Terms & ConditionsCookie settings