Having an issue with Advanced Find->Edit Columns.
I have a Lead and Opportunity entity. They both have a 1:N relationship to the same custom entity (Response). Display options for relationships are "Use Plural Name."
I go to Advanced Find. I select Lead (or Opportunity) in "Look For." I can select Response and then its attributes. Runs fine.
However, when I go to Edit Columns->Add Columns, I do not see Response in the drop down.
Hopefully someone out there has an idea of why this might be.
Thanks.
I think the problem is that Lead could have several related Responses (1:N relationship). But CRM can show only one, and cannot choose which one from related Responses to show. I case you will create view for Responses, you will be able to add fields from either related Leads or Opportunities.
Related
I have one scenario which I am unable to achieve.
Scenario-
I am having Leads entity in which I have n no of leads. In the leads form I have some fields and one sub grid I have added.
Sub-grid is of the form -
Stakeholder name Role of Stakeholder
x Manager
y Budget owner
.
.
.
Now what is happening in sub-grid we are displaying views and whatever we are adding in the views everything will be displayed there in that sub-grid.
Now my requirement is that I wanted to display only the stakeholders and roles of stakeholder which are related to that particular lead not all the data which are there in views and same with other leads in the lead entity.
I have used sub-grid so that I can achieve that multi-column and multi-row way.
So please can anyone help with this problem like how to achieve this thing?.
Note - I just want to achieve "I wanted to display only the stakeholders and roles of stakeholder which are related to that particular lead not all the data which are there in views and same with other leads in the lead entity" That's it. If we can achieve this without using sub-grid then also its fine its just that we should we able to add multiple columns with multiple values.
Thanks in advance!!
you will have to use below settings in your stakeholder subgrid and it shall work.
I would like to provide users with points when they do a certain thing. For example:
adding article
adding question
answering question
liking article
etc.
Some of them can have conditions like there are only points for first 3 articles a day, but I think I will handle this directly in my code base.
The problem is what would be a good database design to handle this? I think of 3 tables.
user_activities - in this table I will store event types (I use
laravel so it would probably be the event class name) and points for
specific event.
activity_user - pivot table between user_activities and users.
and of course users table
It is very simple so I am worrying that there are some conditions I haven't thought of, and it would come and bite me in the future.
I think you'll need a forth table that is simply "activities" that is simply a list of the kinds of activities to track. This will have an ID column, and then in your user_activities table include an 'activity_id' to link to that. You'll no doubt have unique information for each kind, for example an activities table may have columns like
ID : unique ID per laravel
ACTIVITY_CODE : short code to use as part of application/business logic
ACTIVITY_NAME : longer name that is for display name like "answered a question"
EVENT : what does the user have to do to trigger the activity award
POINT_VALUE: how many points for this event
etc
If you think that points may change in the future (eg. to encourage certain user activities) then you'll want to track the actual point awarded at the time in the user activities table, or some way to track what the points were at any one time.
While I'm suggesting fourth table, what you really need is more carefully worded list of features to be implemented before doing any design work. My example of allowing for points awarded to change over time is such a feature that you don't mention but you'll need to design for if this feature is needed.
Well I have found this https://laracasts.com/lessons/build-an-activity-feed-in-laravel as very good solution. Hope it helps someone :)
I have a custom entity Stuff and it contains a lookup to Contact. I created a 1:N relation with the latter as primary and the former as related entity.
On the Contact's form I added a subgrid and I only wish to list the instances of Stuff that have the lookup pointing to the currently viewed Contact. However, when I choose Only Related Records, the custom entity isn't in the list (despite it being related via the 1:N relation).
So, I'm using All Record Types, instead, but that shows all the instances of Stuff and not, as I wish, only those that are related to the currently viewed member.
So, what's the best course of action here? Should I do something with the relation? Or build a custom filter in JavaScript? How can I make the Stuff related to Contact if it's at all possible?
The image below shows the available conditions for the related entities. I notice that none of them relates to Contact, though. Do I need to activate it somehow or am I approaching it from a totally wrong angle?
So to give you more detail, you add the grid on the form:
(This is coming from the contact Form edit, after you press add subgrid)
you select there only related records, this are the stuff record i created:
As you can see only 3 of them has a lookup pointing to a valid contact, from there if you look at the grid, is showing only the related ones as you selected during the grid creation:
In any case i update the answer this is how the relationship is defined, and is a simple lookup created from the stuff entity:
I want to modify the view of 'Activity' entity, opened the view and try searching for edit filter criteria option and it's not available on view form.
please see below
Can you please help to advice me on how I can add filter criteria for this view above. Or how to make it visible the option 'Edit filter criteria' on the form of a view.
Any suggestion will be much appreciated. Welcome for any feedback...
I don't know any way to do that, but you can do your custom views and for example change the default view for that entity. With custom view you can change everything.
See here step by step: http://www.powerobjects.com/blog/2008/08/11/creating-and-editing-views/
What you want is impossible to achieve. Pedro's suggestion is your only option. Create your own Activity view, and then you can create your own filters. You definitely cannot create your own Associated Views. Public Views are the only ones you will have a hope of creating or modifying, and in this particular case, you are still restricted.
There are various places spread throughout CRM where you will run into problems like this, where an entity, view, or field is "locked down". This is the cost of starting with platforms like CRM which are a blackbox that only offer customization up to a certain point.
The problem in this specific case has to do with the nature of activities and the various activity types. Under the hood, there really is not a traditional record type for Activities. The Activity entity is really a "pointer entity" (note the internal name "activitypointer"). Activities really point to other entity types (in this case Activity Types) such as Email activities. The Email entity is more of a traditional entity which you can run standard queries against--but even still that is "locked down".
This additional layer of complexity makes dealing with Activities programmatically more difficult (ex. querying the data, modifying the data via a plugin/SQL, etc.) and, in this particular case, makes even the most basic customizations impossible.
I have an e-commerce website where it is necessary to make a number of associations e.g. a product needs a category, manufacturer, associated products, etc.
When there is only a fairly small, limited amount of data e.g. Manufacturer I simple use a drop down or option boxes for the user to pick the relevent field / fields.
However for items such as associated products, where I have thousands or products it is not viable to use one of these methods. At the moment I use a searchable / paged table that the user then clicks a button to add the association, this works, but it is pretty time consuming for the user and not what I would consider an ideal solution to the problem.
Has anyone implemented a solution to this problem or could they offer any advice as to how they would come at this from a UI standpoint?
Thanks for any help you can be
The solutions I can think of are:
Auto-complete
Recent associations
Smart associations
There may be more depending on exactly what you're doing, so feel free to add more details or screenshots and I'll think on it more.
Auto-complete
Using an auto-complete field would speed up the process for your users since they wouldn't have to hunt through the table for the association. Rather they could just start typing and have a suggest box appear below the field that allowed them to select what they're looking for.
If you matched your auto-complete on several key fields (i.e. manufacturer and product name), there's a pretty good chance that the user would be able to find the association quickly.
You could also code the suggestion box in such a way that it showed multiple pieces of key data. That way if the user wasn't quite sure what they were looking for, typing a few characters in the field would give them an idea of what they could search with.
Recent Associations
Below your auto-complete field, you could add the 5 to 10 most recent associations that had been made. That would allow your users to quickly add many products to the same association without having to use the auto-complete each time.
Smart Associations
Separate from the above two mechanisms, a smart association is something I first saw when theming a Shopify store. They allow you to automatically create associations based on the products key fields by defining conditions to include or exclude products:
Create Association 'Pants'
Where product title contains string 'pants' or
Where product title contains string 'capri'
The above is controlled by a set of dropdowns and textfields and got around the pain of manually creating associations.