Skip to main content

Filter by idea status

10000+ Ideas

garryp16846478New Participant

Build Models for AI features (Auto-Target, Auto-Allocate etc) based on specific environmentsInvestigating

Description - We have been trialling a number of Auto-Allocate/Target activities and we have unearthed that due to our geographical position we are unable to separate specific market/environment activities from the default environment when there are multiple environments present. The attempts to trial market specific activities results indicate that AI does not have an impact and the added reports (Pers. Insights/Important Attributes reports) not present. With the current documentation outlining that any activity that incorporates the default and another environment that it outlines the hits and conversions are 'Considered' but essentially requests are all served by the default environment. Why is this feature important to you - It is important to be able to run the AI tools within Target that are not reliant on using and including the default environment which is a huge limitation for us. This enables market separation when launching a new AI delivered activity.  How would you like the feature to work - When creating a new Auto-Target/Allocate/Personalisation activity having the option to determine which markets/environments for the activities models to be based on(Single or Multiple). Currently any test has to include the default, each of the activities should be dependant on the environment/market you want to run an activity on or on multi environment activities to select what environment is the decisioning source.  Current Behaviour - We are currently using Auto-Allocate and Auto-Target, and whilst we have seen success in these tools we've observed and proven that the tools are not usable if you use within markets other than the default environment. For those users who work geographically and want to launch specific experiences for specific markets we are unable to without including the default environment, even then the data from the market is only 'Considered' as apart of the model not a decisioning element. 

lgaertner
lgaertnerLevel 9

A possibility to set user rights in a more detailed and granular wayNew

Description - I am currently trying to find some solutions to be able to set up certain user rights in much more detail than currently seems possible or intended.In the course of this, the way in which the inheritance of rights works hierarchically with shared objects constantly presents us with new challenges. Why is this feature important to you - We want to use portfolios as self-contained silos, so to speak. It would be necessary to be able to assign different rights within a portfolio in a convenient and understandable way. One problem with this is that if a user or a user group has already been given certain rights at a higher level, these are always inherited completely downwards via programs, portfolios, tasks, etc. and the inherited rights always override any additional, more restrictive rights.Inheritance cannot currently be deactivated via the API. Although there is an unofficial workaround that can also be implemented in Fusion, the complexity leads to quite complex and therefore error-prone Fusion scenarios. In addition, there are simply too many different places in the system where access rights are set (Sharing settings on objects, access levels, templates, ...). All of this means that a lot of trial and error with many errors is necessary in order to implement certain requirements or to recognise that something is not possible. I would like to give you an example to illustrate this. We would like to restrict a specific user group to be able to only download documents from a specific folder on a task and if accessing other folders to see the documents, but not being able to download those. If the user group has access to the parent project, the users have download access to all files due to inheritance, regardless of which folder they are in.Setting up an additional sharing right on a folder to restrict the download possibility for this group is ignored because of the inheritance from the parent projekt / task.So it would be necessary to turn of inheritance here. I would prefer it to be possible to overrule inherited rights. Looking into the Access Levels, there is a possible additional restriction to Never inherit document access from projects, tasks, requests, etc...Nice approach, but that means, that the access rights need to be set for any document. A rule on a folder is completely ignored for the containing documents. Apart from the fact that it took and still takes me a lot of time to find out and understand these peculiarities of the system, you may come across other challenges in other places.Maintenance and ensuring that users are really only allowed to do what they are supposed to do is also a very difficult task at the moment.  How would you like the feature to work - more detailed and granular way to setup user rights to have a much more flexible application Current Behaviour - as described above.

lgaertner
lgaertnerLevel 9

A possibility to set user rights in a more detailed and granular wayNew

Description - I am currently trying to find some solutions to be able to set up certain user rights in much more detail than currently seems possible or intended.In the course of this, the way in which the inheritance of rights works hierarchically with shared objects constantly presents us with new challenges. Why is this feature important to you - We want to use portfolios as self-contained silos, so to speak. It would be necessary to be able to assign different rights within a portfolio in a convenient and understandable way. One problem with this is that if a user or a user group has already been given certain rights at a higher level, these are always inherited completely downwards via programs, portfolios, tasks, etc. and the inherited rights always override any additional, more restrictive rights.Inheritance cannot currently be deactivated via the API. Although there is an unofficial workaround that can also be implemented in Fusion, the complexity leads to quite complex and therefore error-prone Fusion scenarios. In addition, there are simply too many different places in the system where access rights are set (Sharing settings on objects, access levels, templates, ...). All of this means that a lot of trial and error with many errors is necessary in order to implement certain requirements or to recognise that something is not possible. I would like to give you an example to illustrate this. We would like to restrict a specific user group to be able to only download documents from a specific folder on a task and if accessing other folders to see the documents, but not being able to download those. If the user group has access to the parent project, the users have download access to all files due to inheritance, regardless of which folder they are in.Setting up an additional sharing right on a folder to restrict the download possibility for this group is ignored because of the inheritance from the parent projekt / task.So it would be necessary to turn of inheritance here. I would prefer it to be possible to overrule inherited rights. Looking into the Access Levels, there is a possible additional restriction to Never inherit document access from projects, tasks, requests, etc...Nice approach, but that means, that the access rights need to be set for any document. A rule on a folder is completely ignored for the containing documents. Apart from the fact that it took and still takes me a lot of time to find out and understand these peculiarities of the system, you may come across other challenges in other places.Maintenance and ensuring that users are really only allowed to do what they are supposed to do is also a very difficult task at the moment.  How would you like the feature to work - more detailed and granular way to setup user rights to have a much more flexible application Current Behaviour - as described above.

End Date Field References Start Date Field By DefaultNew

When a requestor fills out my form, they choose the Start date (which defaults to today's date). Then they choose the End date (which also defaults to today's date). Is there a way (maybe in Text Mode?) that we can make the second field (End date) defaulted to select the previously entered Start date value, since the End date should always come after the Start date?I'm always trying to reduce form clicks for my team. Requestors are noticing the behavior when entering numerous issues with the same form, specifically when using Start and End date fields in tasks and issues (also with default Calendar month at load-in). It takes extra time to select the End date, and is very obvious when flow is repeated numerous times. Maybe when a date field is added following after another date field, or, maybe when two date fields are set side-by-side (same line), then the second (End) date would allow the user to reference the first (Start) date. You could use the "Add Logic" menu and UI to reference the first form, with a function drop down with the option/value to "reference start date". That would be very cool. Right now, even if you select a Start date of Jan 1, 2035, the End date field will always default back to today's date, causing you to have to click a lot to get back to the year 2035, just to select the next day for the End date, resulting in double the amount of clicks for each issue created. Thanks!