Product ideas | Community
Skip to main content

Filter by idea status

10000+ Ideas

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. 

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.

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.