Badges
Accepted Solutions
Likes Received
Posts
Discussions
Ideas
Blog Posts
That does indeed look counterintuitive. With workspaces however I do presume you mean partitions, but other than that I agree with your logic.
Not too sure I would mix data from different clients in a single instance in the first place. For starters, an unsubscribe for one client will mean the same email address is unsubscribed for all. Not to mention other potential duplicates pitfalls.
It turns out program tokens can be in use in very strange ways, which makes it a necessity to have the "used by" functionality for program tokens. A use case I came across today:Original token is set up in a campaign folder.Someone erroneously made changes to the inherited token in a program that wa...
It's actually not entirely the same @Michael_Florin . I always select the program level as a filter, but when the report is in a subfolder it still does not update for a cloned program.
Any reports that are set up within a program of course are meant to report on that program specifically. When cloning a program, reports that are set up directly under the program itself are updated automatically. However, when you apply some housekeeping on more complex programs and put reports int...
Anyone else find it strange that when you select specific folders to include in a report the old program icons are still used?
Makes total sense to me. You would not want all users to be able to do this.
Currently, allowing global reporting can only be enabled in an instance's Default workspace. There are however use cases where this would be useful to allow in other workspaces (instead or as well). Taking it one step further, it would be good if a user could select which workspaces to include in a ...
You can adjust that in the settings of your account.
In addition, we cannot seem to use the PMCF fields in constraints and choices too well. It is really difficult to monitor if a specific program member field was updated to a specific value or already contains data.