Skip to main content

Ideas

Filter by idea status

10000+ Ideas

Adilos-Cantuerk
Community Advisor
Adilos-CantuerkCommunity Advisor

FPO - essential function - JPG can not display transparency - additional slider for PNGalpha can fix the feature.Investigating

Request for Feature Enhancement (RFE) Summary: I suggest to have a PNG option for the FPO setting slider to enable a seamless working with assets that do rely on transparency. Use-case: FPO Renditions for InDesign Asset Link are OOTB only available as JPGs.This file format does not meet the needs of modern print media production workflows, since images rely more heavily on transparency settings instead of cutting paths. This change is not very new and i have seen companies made that switch from cutting paths to transparency back in 2010. This makes JPG a suboptimal choice for FPO renditions since this format is not capable of containing transparent pixels. The picture would be flattened on a white background. Current/Experienced Behavior: FPO is simply not an option on every asset that has a transparent background. This goes for pretty much every single product picture within our AEM.Since the setting is applied via Folder setting, we have to manualy delete the FPO renditions on assets that need its inbuilt transparency to be able to layout correctly in InDesign (since JPG does not hold any transparency) and to make things worse - this increases the loading time significantly for bigger print media cataloges, since InDesign will load the orignal files into the cache every time the user checks out the cataloge. We are talking 10Gig every single checkout.To make the FPO a good thing - it needs to have more options than just JPG. Improved/Expected Behavior: Give users more than just JPG as a FPO format. I suggest PNGalpha since it would meet the transparency criteria, yet there might be some additional things i don't have on my radar.  Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS 2023.12.14697.20231215T125030Z Customer-name/Organization name:   Screenshot (if applicable):   Code package (if applicable):  

FrederikWerner
Community Advisor
FrederikWernerCommunity Advisor

Easily accessible date granularity toggles for line charts in Analysis WorkspaceNew

Description - Everybody loves a good line chart. With line charts, you can easily see numbers, but on a line! It's amazing! But I think it could be even more amazing. In many Analysis Workspace projects, I see some sort of line chart for top-level metrics and trends, like this one: Now, depending on how our stakeholders would use this project, they might want to change the granularity of the chart to reflect longer-running campaigns, sudden traffic increases, and many more use cases. To do that, they currently have two options: Find the connected Freeform table, drag and drop a new granularity in there, and hope it doesn't go wrong OR do it directly on the chart by (finding and) clicking the little gear icon: Now, while those methods work well enough once you a) know where to find the option and b) remember where it is hidden, we might have an opportunity here to make it just a bit easier for people to play with granularities, especially if they only use Workspace every now and then. To achieve that, I proudly propose to you: The same, but slightly different: Now, we have a quickly accessible, not-scary, simple-to-understand way to change granularities without having to find the gear icon or any drag and drop. Amazing! All it needs is this little group of buttons (or, for the cool kids, a Coral.ButtonGroup) that might only show up when hovering over the chart and possibly can be hidden entirely from the gear box. And, as we all know: Fewer clicks always mean higher adoption, so this might be an easy win! Why is this feature important to you - Because I want my stakeholders to work with the data on their own instead of asking me time and time again how to change granularities, so I can spend more time doing what I love: Fixing GenAI errors (or whatever the much cooler analysts do these days) How would you like the feature to work - Like above Current Behaviour - Many clicks for few changes, therefore fewer changes, and more "quick 5-minute calls" with stakeholders

Align Opportunity Identification Across API BehaviorsNew

As a technical solution provider, I would like to provide enhanced opportunity information across Marketo behaviors--and ideally, without the use of a separate CRM. However, when a CRM is attached to Marketo, there are several issues with translating Marketo opportunity activity: Activities such as Add to Opportunity/Remove from Opportunity/Update Opportunity (Activity IDs 34-36) use an integer as the identifying value for an opportunity. For example, a recent "Add to Opportunity" activity returns the following:{"id":98506929,"marketoGUID":"98506929","leadId":2054980,"activityDate":"2024-05-01T09:40:00Z","activityTypeId":34,"primaryAttributeValueId":72984,"primaryAttributeValue":"Opportunity Name - 2024","attributes":[{"name":"Is Primary","value":true},{"name":"Role","value":"Relevant Executive"}]}, This results in an Opportunity ID value of "72984." While I can work backward using the primaryAttributeValue to match via the opportunity name, this is less than ideal. There is also no reference to any externalOpportunityId, which would be used in this case (the instance is synced to an SFDC instance).Querying Marketo's own recording of opportunities independent of the CRM results in displaying a UUIDv4 value, but there is no reference to either the integer value on the Opportunity-related Activities value that could be used to cross-reference between systems:{"requestId":"11802#18fdeddf644","result":[{"seq":0,"marketoGUID":"be320968-423a-48e2-9730-e2e08df61fae","externalOpportunityId":"0061R00000m3kRLQAY","updatedAt":"2023-09-06T01:27:58Z","createdAt":"2018-12-17T15:43:08Z"}],"success":true}The marketoGUID is written activity-style rather than reading from the integers recorded in the opportunity-related activity. This leaves no way to resolve Marketo's own ID systems to tie the data together.Could you provide either the GUID in the activity or the integer in the main Opportunity query? Likewise, since something is translating the integral Opportunity ID to the Salesforce Opportunity Name, could the externalOpportunityId be exposed as a value on Opportunity-related activities? Otherwise, this data is disjointed and can only be poorly unioned together.

William
Community Advisor
WilliamCommunity Advisor

Enable "Admin View Access" in Access LevelsNew

DescriptionAllow us to create Access Levels that have the same benefit of an Administrator by granting them View access to all records across the instance, but allows us to limit their ability to modify, create, or delete records. Why is this feature important to youWe have a number of accounts that are designated as service accounts. To protect our data from being inadvertently modified or deleted, we have to create a custom view-only Access Level that allows the service account to read records but not modify, create, or delete records. This means we have to spend a lot of time ensuring these service accounts are shared on all the relevant records in our instance. It would save a lot of time and energy if we could create Access Levels that allow an account unlimited read access, but limited write/delete access. How would you like the feature to workEnable an option on the Access Level editor to grant "Admin View Access" which would allows accounts using that Access Level to view/read any record in the instance while still allowing us to customize which objects the Access Level can create, modify, or delete. Current BehaviourWe cannot assign the Administrator Access Level to our service accounts without accepting the risk that those accounts may overwrite or delete data. We therefore create view-only Access Levels to assign, then spend a lot of time and energy making sure the service accounts are shared on everything. The ability for us to create a "view-only with admin rights" account would be safer and easier for us to manage.