@sebastiane27965, so what happened to your implementations? Did the Old
DTM codes overwrite your new Launch embed codes or were the Launch embed
codes correct but you were still getting served your DTM production
libraries? I chose not to link our production Launch code to our
production DTM code too so I am interested in hearing more about this.
Have you tried disabling your old DTM property now that you have
migrated over to Launch? This might solve your issue by disallowing the
Launch embed c...
We have used the DTM to Launch property migration button to get several
of our properties migrated over from DTM to Launch. Upon closer
examination of the Launch property today, it looks like rules that were
inactive in DTM were not copied over to the newly created Launch
property. Has this happened to anyone else, or is this something that is
unique to our company?
@Haran_Huang, the vast majority of our event based rules have values
that are hardcoded like the example above and do not use data elements.
Also, even when you are using data elements in this field, it still gets
truncated with a (...) when your data element is longer than 27
characters. Since we have quite a few data elements whose names are
longer than this, these would get partially obscured in the value field
It would be great if we could make the input field for the Evar/Prop
string wider so you could see more characters. This would save time as
it would reduce the number of times a user would have to spend moving
the cursor further to the right and help make it easier to spot typos
that are off screen when a user opens up the Set Variables component of
a particular rule.
Currently, you can build/advance a library from the publishing tab as
there is a dropdown menu with three horizontal dots that allows you to
do this without opening up that specific library. However, you still
need to open the library up in order to remove or add an environment
when the library is in the development column. It would be nice if you
could remove and add environments from development libraries in a
similar way without having to individually open each library to remove
or add enviro...
@courtneya707225, you should be able to use the same host for multiple
environments. I have three embed codes for most of my Launch properties
and I use a single host that I set up for all three of those
environments. One host can work for multiple properties as Launch
doesn't force you into having a 1:1 relationship between host and
properties. You can have one host for five different environments or you
can use different hosts for each of your environments.
It would be great if the rule search feature in launch was case
sensitive. Currently, we use abbreviations like "CC" in the rule names
that have custom code in them. When you search that in Launch you get
both that acronym and rules that contains words with "cc" in them.
Example Rule Name: "Medicare Plans - Patient Plans Accordion" would come
up if you inputted "CC" in the search box.
Yes, I am not sure if this was where you were going but it would be
great if the name field could default to some combination of the
Identifier Used + Identifier Type when you add something in that field.
Here are some examples of what I was thinking below. Currently, I am
doing this manually by editing the name field for each rule but it would
be awesome if it was done automatically.
Currently only the libraries in the published column display the date
they were published. It would be very helpful if libraries that have
been built to development or staging displayed the date they were last
built in the same manner. This would save a lot of time since you
wouldn't have to go open up each library in order to see what date it
was built last. In some of my Launch properties I have 10-12 libraries
waiting in the development queue for code fixes from our developers. If
this was im...
Yes, this is an awesome idea! The overview page appears to me to be
mainly for new Launch users. If people use Launch every day that page is
irrelevant and a waste of space. Another option would be to default the
user to the Rules page after they click a specific Launch property in
the Company view since the Rules page is used more often than the
When you create a Launch mobile property it only includes instructions
for installing the AEP SDK for fully native Android and iOS
applications. The ReactNative instructions are found in the Adobe
documentation (see link below) but are not readily available in Launch
and you must combine that code with the appropriate environment file ID
from your Launch property as well. It would be nice if these ReactNative
instructions were present under the Environments tab inside of Launch
for all mobile pr...