I am quite new to salesforce
There is a field called "Hard Construction Cost" which is Currency type value.
Then there is another fields called "Hard Construction Cost per sqft" which is Currency type and "Max GBA" which is a number type
The field "Hard Construction Cost" needs to be updated like this : max GBA * "Hard Construction Cost"
but the workflow rule isnt work..
any idea why??
If that field doesn't require user input and is only calculated field then instead of workflow you can use formula field.
Create a formula field with name Hard Construction Cost
your formula will be
Hard_Construction_Cost_per_sqft__c * max_GBA__c
Related
We are using scoring profile for driving the relevance and adjusting scores i.e. boost the relevance for a attribute isActive is 1 by 50 using function in scoring profile, While searching for a specific fields on the Index by passing &searchFields=******
however Search.Score seems highly squeezed by size of the document , smaller the size high score probably due to TF-IDF…..
And this is defeating the purpose of using scoring profile , however in our case we don’t want score to be impact due to size of document since we are passing searchFields.
Cases where searchFields are not passed we want scores to be adjusted by size i.e. free form search in all searchable fields.
example search query -
agency temps&$count=true&$top=30&$skip=0&searchMode=All&$filter=(CompanyCode eq '13453' and VNumber eq '00023232312016') &scoringProfile=BusinessProfile1&searchFields=VCategory
I wonder if the new featuresMode preview capability would be helpful for you? Using this, you can get a lot more information back from the search query such as uniqueTokenMatches and termFrequency on a field by field basis. Using this, you could adjust the ordering as needed on the client side.
Also, you are correct that the default is a TF-IDF like scoring, however, you might also be interested in trying BM25 which although does not solve what you are asking for, could be more effective for helping to get scores you are looking for.
For now I adopted the approach to adjust the parameters for algorithm BM25 as advised by Liam, and added b as 0.0 in index creation json, so that document size is not used during TF-IDF while calculating score for the document,
"similarity": {
"#odata.type": "#Microsoft.Azure.Search.BM25Similarity",
"b" : 0.0,
"k1" : 1.3
}
however same time identified another field on the index having a correlation with size of the record on the index i.e. larger the size higher the value of that field and using that in scoring profile for the case where document size should be considered in scoring.
I'm putting together a query to index medicines. A user should be able to enter their search term into a single search box. Their search term might be either a brand name for a drug, a generic name (the underlying compound on which all brands are based) or an indication and they should be returned a list of medicines that correspond to their search. I'd like to have a category facet for the type - either indication, brand or generic.
To have a category facet, my understanding is that I'd have to send my data through as one row per search term where that search term might be a brand, indication or a generic, rather than one row per brand with columns for generic list and indication. Is this correct or is there another way to get at what I'm wanting to do?
I hope I understand your ask here. From the screenshot you provided, I would assume what you would want to do is make the field "MedicineInformationType" a Facetable field in your Azure Search index and make the field "SearchTerm", "Product", "GenericList", and "ActionList" all Searchable fields in your Azure Search index (although I am not sure why you would want the "SearchTerm" field if the term in this field is already in one of the other fields).
If you structure your index this way, you can do a search for say "phosphate" and facet over the "MedicineInformationType" field to get a count of the results that are generic or brands.
For example (as a REST call):
search=phosphate&facet=MedicineInformationType
Let's say that we have an index with two objects:
{
"name": "iPhone 6s Plus big screen, super fast, ultra responsive, blah blah"
}
and:
{
"name" : "iPhone 6s Plus"
}
Now, when i search for iPhone 6s Plus, it returns the first object which does not make sense, since the first object contains more words (or noise) than the second object for the given query. In other words, a term appearing in a short name field should carry more ranking points than the same term appearing in a long name field
Algolia uses a TF/IDF algorithm, which takes account of the Field-length norm, so the second object should have higher score than the first one.
So why does the first object has higher score than the second one? Is there any settings option that I am missing?
I found the answer, but I am not sure if it is 100% correct, or if there is a better way to achieve this.
Login to Algolia -> Select Your Instance -> Go to Ranking Tab.
In the Ranking Formula, add a new row. The new row, should have Attribute type {{the name of the column, in this example is "title"}} and set it to Ascending.
With that, you will achieve what we are looking for.
One option is to break up the value into two different attributes, one for just the product name and another for the description. Doing that also lets you prioritize the product name in your searchable attributes, which would lead to better relevance in most cases.
I've got a text field that can potentially have multiple values.
doc 1:
field a:"X Y"
doc 2:
field a:"X"
I want to be able to do :
a:X^5
And have both doc 1 and 2 get an identical score.
I've been messing around with all the field options, but I always end up with doc 2 getting double the score of doc 1.
I've tried setting multiValued="true", but get the same result.
Is there someway that I can set my search or the field definition so that it will boost just based upon the existence of the search term and not be effected by the rest of the field's contents.
Disable norms by setting omitNorms=true in your schema and reindex - it should disable the length normalization for the field and give you the desired results.
For more details of what omitNorms does, see this.
The field a of doc 2 has only one term as compared to doc 1 which has two.
Solr DefaultSimilartiy implementation takes into account the length norm, number of terms in the field, for the fields when calculating the score.
LenghtNorm is 1.0 / Math.sqrt(numTerms)
LengthNorm allows you to make shorter documents score higher.
You can provide your own implementation of Similarity class which doesn't take into account the lengthNorm.
Check computeNorm method implementation.
You can turn of the Norms using omitNorms=false.
Norms allow for index time boosts and field length normalization. This allows you to add boosts to fields at index time and makes shorter documents score higher.
So you would lose both of the above if you use it.
Is it possible to make an editable formula field in an object?
A formula field is not editable. You could create an "override" field. This is the formula for the formula field:
IF(ISBLANK(OverrideField), "Formula value here", OverrideField)
If OverrideField has a value, it is used. Otherwise, the "formula value here" value is used. You should change "formula value here" to an expression that you want in the formula field.
It is not possible to make formula field as editable.formula field is a read only field.
While not a formula field, you could also create a workflow rule which populates a field only when that field is empty. Set up the workflow to fire whenever the field value is blank. Then, as your action, create a field update that sets the field to your formula value.
The downside of this is that the field value will only be updated when the record is saved and the field is blank. This differs from formulas in the fact that a formula field is updated every time the record is viewed. Depending on your specific use case, this may be an issue.